Tốc độ có thể là một lợi thế vì lý do này và bất lợi cho lý do khác.
Khi nói đến bảo mật mật khẩu, các yêu cầu về bộ nhớ/cpu thấp của hàm băm mật mã mang lại một bất lợi, cụ thể là nếu các bản ghi hoặc cơ sở dữ liệu bị lộ hoặc bị tấn công, kẻ tấn công có rất ít việc phải làm để biến các hàm băm đó thành văn bản gốc mật khẩu mở khóa.
Điều này là do mật khẩu thường ngắn và có ít entropy hơn so với bảo mật hình ảnh trước của hàm băm. Nếu mật khẩu lớn và ngẫu nhiên, chẳng hạn như 32 chữ cái và số ngẫu nhiên, thì một lần lặp nhanh duy nhất của hàm băm là quá đủ.
Để bảo mật, bạn muốn một "chức năng băm mật khẩu" chiếm càng nhiều thời gian (tài nguyên tính toán) và bộ nhớ càng tốt để làm chậm các cuộc tấn công hàng loạt. Tuy nhiên, điều này trở thành một bất lợi đối với máy chủ sẽ so sánh hàm băm với giá trị cơ sở dữ liệu, vì trong hầu hết các trường hợp, máy chủ đó phải tính toán hàm băm từ mật khẩu do người dùng cung cấp.
Kẻ tấn công có thể khai thác nhược điểm đó bằng cách tiêu tốn một lượng lớn tài nguyên thông qua các nỗ lực đăng nhập hàng loạt được phối hợp của những tên người dùng đã biết hoặc dự kiến, thực sự là một cuộc tấn công từ chối dịch vụ băng thông thấp, máy chủ quá bận rộn để theo kịp các nỗ lực đăng nhập giả mà người dùng thực không thể đăng nhập.Điều này có thể được giảm thiểu bằng cách điều chỉnh các nỗ lực truy cập trên mỗi địa chỉ IP, mỗi tên người dùng và cũng có thể thêm độ trễ trước khi lỗi đăng nhập được hiển thị. Nếu người dùng không tồn tại, máy chủ sẽ không băm mật khẩu, nhưng sẽ trả về lỗi với độ trễ thích hợp như thể người dùng đã tồn tại, để kẻ tấn công không thể suy ra sự hiện diện của tên người dùng trong cơ sở dữ liệu.
PBKDF2 là một hàm băm mật khẩu cực kỳ phổ biến và cốt lõi của nó thường sử dụng HMAC, vì vậy, một số vòng như 40000 vòng PBKDF2-HMAC-SHA256 thực sự có thể mất khoảng 80000 lần so với một lần lặp lại hàm băm. Nếu trước đây máy chủ có thể thực hiện 4 tỷ lần lặp băm mỗi giây, thì giờ đây, máy chủ chỉ có thể thực hiện 50000 lần băm PBKDF2 trước khi làm bão hòa hoàn toàn CPU của nó. Nếu bạn muốn không quá 10% tài nguyên được phân bổ cho việc kiểm tra mật khẩu, thì nó cần phải được điều chỉnh ở mức 5000 lần đăng nhập mỗi giây... nghe có vẻ nhiều, nhưng bạn nghĩ có bao nhiêu người đăng nhập vào một thứ như Gmail, Lastpass hoặc Salesforce vào khoảng 9 giờ sáng Thứ Hai?
Phải có một cấu hình cân bằng và đủ phần cứng để xử lý tất cả thông tin đăng nhập của người dùng ngay cả khi tải nặng mà không gây ra độ trễ đáng kể cho những người dùng đó và ngăn những kẻ xấu từ chối dịch vụ đối với những người dùng đó. Độ mạnh của hàm băm mật khẩu cũng có thể cần thay đổi theo thời gian khi tài nguyên của kẻ tấn công tăng lên, mô hình mối đe dọa thay đổi, v.v. Chi phí cho thiệt hại về danh tiếng có thể cao hơn nhiều lần so với chi phí phần cứng để thực hiện hàm băm mật khẩu rất đắt đỏ.
Có những tình huống khác mà nhanh chóng là một bất lợi? Tôi thực sự không thể nghĩ ra bất kỳ điều gì, các hàm băm thường được sử dụng như một phần của sơ đồ, chẳng hạn như chữ ký số có liên quan đến thuật toán bất đối xứng đắt tiền về mặt tính toán, bảo mật trong trường hợp đó đến từ kích thước của hàm băm và sức mạnh hiệu quả của khóa ký, không phải tốc độ của hàm băm.
