Salting trong bảo mật là gì? Giải thích về băm mật khẩu.
Vào tháng 6 năm 2012, một kẻ tấn công đã tung 117 triệu hồ sơ tài khoản LinkedIn lên một diễn đàn của Nga. Danh sách này là một bức tường gồm các mã băm SHA-1 không có muối. SHA-1 rất nhanh. Không có muối để tách các mật khẩu giống nhau, cùng một mã băm xuất hiện cạnh nhau hàng nghìn lần. Trong khoảng 72 giờ, các nhà nghiên cứu bảo mật đã giải mã được khoảng 90% tập tin. Khi vụ rò rỉ này được phát hiện lại vào tháng 5 năm 2016 như một phần của tập dữ liệu gồm 167 triệu hồ sơ, những thông tin đăng nhập đó đã được sử dụng cho các chiến dịch tấn công đánh cắp thông tin đăng nhập trong nhiều năm.
Biện pháp phòng vệ có thể làm giảm nhẹ mức độ nghiêm trọng của vụ rò rỉ dữ liệu – thêm "muối" vào mọi mật khẩu được lưu trữ – đã tồn tại từ năm 1979. Nó được gọi là kỹ thuật "salting" (thêm muối vào mật khẩu). Kỹ thuật này không mới, không tốn kém và cũng không đặc biệt thông minh. Nó tạo nên sự khác biệt giữa việc một vụ rò rỉ dữ liệu được kiểm soát và việc nó trở thành vấn đề mật khẩu của tất cả mọi người trong suốt nửa thập kỷ.
Hầu hết các lỗi lưu trữ mật khẩu hiện đại vẫn bắt nguồn từ cùng một nguyên nhân: ai đó đã quyết định rằng "chúng ta sử dụng SHA-256" là đủ tốt. Bài viết này sẽ đi sâu vào việc muối mật khẩu thực chất là gì, cách thức hoạt động trong thực tế, những gì nó có thể và không thể bảo vệ chống lại, và OWASP khuyến nghị gì là mặc định vào năm 2026.
Trong bảo mật và băm mật khẩu, "salting" là gì?
Tóm gọn chủ đề thành một câu. Salting nghĩa là thêm dữ liệu ngẫu nhiên vào mật khẩu trước khi mật khẩu đó được băm. Giá trị ngẫu nhiên – hay còn gọi là salt – được tạo ra một lần cho mỗi tài khoản khi salt được tạo cùng với mã băm mật khẩu mới, được lưu trữ công khai bên cạnh mã băm kết quả và được đọc lại mỗi khi đăng nhập. Nó không phải là khóa. Không phải là bí mật. Không phải là mã hóa. Nó là một công cụ sửa đổi công khai với chính xác một nhiệm vụ: đảm bảo rằng khi hai người dùng có cùng mật khẩu, họ không bao giờ chia sẻ cùng một mật khẩu đã được băm được lưu trữ.
Bản thân hàm băm chỉ là một chiều. Khi chạy mật khẩu qua SHA-256 hoặc Argon2id, bạn sẽ nhận được một giá trị có độ dài cố định mà không thuật toán nào có thể đảo ngược được. Vấn đề là "không thuật toán nào" loại trừ một lối tắt đơn giản – tra cứu giá trị băm trong một từ điển đã được tính toán trước. Việc thêm muối (salting) sẽ loại bỏ lối tắt đó. Thêm muối vào quá trình băm sẽ tạo ra một giá trị băm duy nhất cho mỗi người dùng, ngay cả khi văn bản mật khẩu gốc của họ giống hệt nhau từng chữ. Các mật khẩu thông dụng như "password" và "qwerty" sẽ không còn xung đột trong cơ sở dữ liệu nữa. Việc thêm muối đảm bảo rằng việc rò rỉ một hàng dữ liệu không cho kẻ tấn công biết gì về bất kỳ ai khác.
Có ba quy tắc phân biệt một chuỗi muối (salt) có thể sử dụng được với một chuỗi muối vô dụng. Quy tắc đầu tiên: mỗi mật khẩu đều có một chuỗi muối ngẫu nhiên riêng, được tạo mới khi người dùng đăng ký hoặc đặt lại mật khẩu. Một mật khẩu có sử dụng chuỗi muối và được sử dụng lại trên nhiều tài khoản hầu như không tốt hơn mật khẩu không có chuỗi muối — cuộc tấn công hàng loạt hoạt động theo cùng một cách. Quy tắc thứ hai: chuỗi muối có thể được công khai. Chỉ cần biết chuỗi muối cũng không cho phép kẻ tấn công có bất kỳ lối tắt nào để tìm ra hàm băm cơ bản. Vì vậy, chuỗi muối nằm trong cơ sở dữ liệu bên cạnh hàm băm, và vị trí đó là ổn, thậm chí được khuyến khích. Quy tắc thứ ba: các giá trị của chuỗi muối đến từ một bộ tạo số giả ngẫu nhiên an toàn về mặt mật mã. Linux cung cấp một bộ tạo như vậy thông qua `getrandom(2)`. Node gọi nó là `crypto.randomBytes`. Thư viện chuẩn của Python gói gọn nó trong `secrets.token_bytes`. Hàm `Math.random()` không an toàn về mặt mật mã là không phù hợp, mặc dù nó xuất hiện trong mã được kiểm toán thực tế thường xuyên hơn mức cần thiết.
Hai người dùng chọn "hunter2" làm mật khẩu sẽ nhận được hai mã băm được lưu trữ hoàn toàn khác nhau. Việc thêm muối (salting) là điều giúp điều đó xảy ra. Nếu bỏ qua muối, cơ sở dữ liệu sẽ bị rò rỉ không chỉ mã băm mà còn cả thông tin về việc ai chia sẻ mật khẩu với ai.
Phương pháp thêm muối vào mật khẩu hoạt động như thế nào?
Cơ chế này gồm bốn bước, và mười năm kinh nghiệm về các vụ rò rỉ dữ liệu lưu trữ mật khẩu cho thấy hầu hết các thất bại đều xảy ra do ai đó đã bỏ qua một trong bốn bước đó.
Bước đầu tiên diễn ra khi đăng ký. Ứng dụng yêu cầu một máy tạo số ngẫu nhiên an toàn mật mã (CSPRNG) cung cấp từ mười sáu đến ba mươi hai byte ngẫu nhiên. Đó chính là "muối" (salt). Hướng dẫn năm 2025 của OWASP coi mười sáu byte (128 bit) là mức tối thiểu; Auth0 và một số nhà cung cấp phần mềm quản lý mật khẩu khuyến nghị sử dụng ba mươi hai byte. Tiêu chuẩn SP 800-63B-4 của NIST đặt mức tối thiểu là bốn byte nhưng cảnh báo rằng các xung đột giới hạn theo ngày sinh nhật bắt đầu xuất hiện khi số người dùng đạt khoảng sáu mươi lăm nghìn ở mức đó, đó là lý do tại sao không ai thực sự sử dụng bốn byte.
Bước thứ hai là kết hợp chuỗi muối với mật khẩu do người dùng chọn. Phương pháp nối chuỗi là hình thức phổ biến nhất, trong đó chuỗi muối được đặt trước hoặc sau chuỗi mật khẩu. Một số hệ thống sử dụng HMAC thay thế, coi chuỗi muối như khóa HMAC, giúp tránh một số vấn đề phức tạp về mở rộng độ dài khi nối chuỗi trực tiếp.
Bước thứ ba chạy dữ liệu đầu vào kết hợp thông qua thuật toán băm mật khẩu — cái mà sách giáo khoa mật mã học gọi là hàm dẫn xuất khóa, hay KDF. Đây là bước mà hầu hết các nhóm thường mắc sai lầm, thường là do sử dụng thuật toán băm chung chung và cho rằng công việc đã hoàn thành. SHA-256 thông thường không phù hợp để lưu trữ mật khẩu. Một GPU dành cho người tiêu dùng vào năm 2026 có thể xử lý hơn một trăm tỷ hàm băm SHA-256 mỗi giây, vì vậy ngay cả khi có thêm muối, chi phí cho mỗi lần đoán trong băm mật mã vẫn rất nhỏ. Việc thêm muối giúp loại bỏ các vectơ tấn công bảng cầu vồng. Tuy nhiên, nó không tự làm chậm quá trình bẻ khóa mật khẩu bằng phương pháp vét cạn. Công cụ phù hợp ở đây là một hàm cố tình chậm và tốn nhiều bộ nhớ: Argon2id là mặc định được OWASP ưu tiên, với scrypt và bcrypt được chấp nhận, và PBKDF2 với số lần lặp rất cao được cho phép khi việc tuân thủ FIPS-140 bắt buộc phải lựa chọn.
Bước thứ tư lưu trữ cả giá trị băm và muối. Các thư viện hiện đại xử lý định dạng lưu trữ nên bạn không cần phải tự quản lý muối đã lưu trữ. Đầu ra của bcrypt trông giống như `$2b$12$9f4c8a7b...kQR8YZpL9` — chuỗi duy nhất đó chứa mã định danh thuật toán, hệ số chi phí, muối và giá trị băm. Argon2id sử dụng định dạng chuỗi PHC tương tự, `$argon2id$v=19$m=19456,t=2,p=1$$`. Bạn ghi chuỗi đó vào một cột trong cơ sở dữ liệu và để đó. Thư viện đã thực hiện mọi thứ cần thiết để lưu trữ mật khẩu một cách an toàn — tạo dữ liệu ngẫu nhiên cho muối, chạy mật khẩu qua thuật toán băm chậm và đóng gói kết quả để truy xuất.
Quá trình đăng nhập diễn ra theo cùng một quy trình nhưng ngược lại. Ứng dụng tra cứu salt và hash đã lưu của người dùng, chạy mật khẩu được nhập qua cùng thuật toán với cùng salt đó, và so sánh kết quả với hash đã lưu bằng phép so sánh có độ phức tạp thời gian không đổi. Độ phức tạp thời gian không đổi rất quan trọng: một phép so sánh đơn giản như `==` sẽ làm lộ thông tin về số byte khớp nhau, dẫn đến các lỗ hổng tấn công dựa trên thời gian thực sự. Hãy sử dụng `hmac.compare_digest`, `crypto.timingSafeEqual` hoặc phương thức tương đương của framework bạn đang sử dụng.
Tại sao việc thêm muối lại quan trọng: vấn đề về chiếc bàn cầu vồng
Bảng cầu vồng là kiểu tấn công cụ thể mà kỹ thuật thêm muối (salting) được phát minh ra để chống lại. Hãy tưởng tượng một bảng tra cứu được tính toán trước, ánh xạ mọi mật khẩu khả thi — mọi từ trong từ điển, biến thể phổ biến, mục trong danh sách bị rò rỉ — đến mã băm SHA-256 của nó. Những bảng này tồn tại, chúng được bán trên các diễn đàn bẻ khóa và có dung lượng lên đến terabyte. Một khi kẻ tấn công nắm giữ bản sao cơ sở dữ liệu các mã băm chưa được thêm muối, việc tra cứu mã băm trong bảng cầu vồng chỉ là một truy vấn cơ sở dữ liệu, chứ không phải là một công việc bẻ khóa. Vụ tấn công LinkedIn năm 2012 diễn ra chính xác như vậy: 117 triệu mã băm SHA-1 chưa được thêm muối được sử dụng để tấn công bảng cầu vồng, 90% đã bị bẻ khóa trong khoảng ba ngày.
Thêm một salt riêng cho mỗi người dùng và bảng cầu vồng sẽ không còn hoạt động nữa. Kẻ tấn công sẽ cần một bảng được tính toán trước riêng biệt cho mỗi giá trị salt duy nhất. Với một salt ngẫu nhiên 16 byte, điều đó có nghĩa là 117 triệu bảng khác nhau cho 117 triệu người dùng — và mỗi bảng vẫn sẽ có dung lượng lên đến terabyte. Chỉ riêng chi phí lưu trữ đã khiến điều này trở nên không khả thi. Cuộc tấn công này bị loại khỏi mô hình mối đe dọa.
Đó là toàn bộ chức năng của muối mật khẩu. Nó được thiết kế hẹp một cách có chủ đích. Muối mật khẩu không làm chậm nỗ lực tấn công vét cạn nhắm vào một người dùng cụ thể. Muối mật khẩu không ngăn chặn việc đánh cắp thông tin đăng nhập từ một vụ rò rỉ trước đó. Muối mật khẩu không có tác dụng nếu chính mật khẩu là "123456" — kẻ tấn công sẽ thử từ điển mật khẩu dễ đoán, và muối mật khẩu được tính toán lại cho mỗi lần đoán nhưng không làm thay đổi đáng kể chi phí cho mỗi lần đoán.
Những gì mà việc thêm muối (salting) có thể giảm thiểu một cách đáng tin cậy: bảng cầu vồng (rainbow tables) và việc rò rỉ thông tin về việc sử dụng lại mật khẩu giữa các người dùng trong cùng một cơ sở dữ liệu. Những gì mà việc băm chậm (slow hashing) giảm thiểu: chi phí cho mỗi lần đoán. Những gì mà việc thêm hạt tiêu (pepper) giảm thiểu: việc đánh cắp dữ liệu chỉ trong cơ sở dữ liệu. Những gì mà xác thực đa yếu tố (MFA) giảm thiểu: việc tấn công bằng cách nhồi nhét thông tin đăng nhập (credential stuffing). Việc thêm muối chỉ là một lớp bảo mật trong một hệ thống bảo mật tổng hợp — việc thêm muối để làm cho mật khẩu khó đoán hơn không giống như việc làm cho mỗi mật khẩu riêng lẻ khó đoán. Mục tiêu mà việc thêm muối đạt được là tạo ra một hàm băm khác nhau cho mỗi người dùng; việc làm cho mỗi lần đoán tốn kém là một vấn đề khác.
Hàm băm so với mã hóa so với việc thêm muối
Ba thuật ngữ này thường bị nhầm lẫn, đặc biệt là trong các bài viết của những người không chuyên. Chúng không thể thay thế cho nhau.
| Mã hóa | Băm | Muối | |
|---|---|---|---|
| Có thể đảo ngược | Vâng, kèm theo chìa khóa. | Không, đó là do thiết kế. | Từ bổ nghĩa, không phải từ độc lập |
| Độ dài đầu ra | Biến, khớp với đầu vào | Cố định (thường là 256 bit) | Không áp dụng — thay đổi đầu vào băm |
| Được sử dụng cho | Bảo mật dữ liệu | Tính toàn vẹn, lưu trữ mật khẩu | Tăng cường hàm băm |
| Cần có chìa khóa | Vâng, bí mật | KHÔNG | Không, nó sử dụng muối ngẫu nhiên. |
Mã hóa bảo vệ dữ liệu mà bạn muốn truy xuất sau này. Người nhận giữ khóa, áp dụng nó và đọc dữ liệu gốc. Hàm băm là một chiều: một khi mật khẩu đã trở thành hàm băm, không có thuật toán nào có thể đảo ngược nó. Thêm muối (salting) là một tham số bạn áp dụng cho đầu vào của hàm băm — bản thân nó không có ý nghĩa gì.
Vụ rò rỉ dữ liệu của Adobe năm 2013 là một ví dụ cảnh báo ở đây. Adobe đã lưu trữ 153 triệu bản ghi người dùng bằng cách mã hóa mật khẩu bằng thuật toán 3DES ở chế độ ECB dưới một khóa duy nhất dùng chung cho toàn bộ hệ thống. Lựa chọn đó là một sai lầm kép. Mã hóa không phải là phương pháp phù hợp để lưu trữ mật khẩu. Chế độ ECB làm rò rỉ các đầu vào giống hệt nhau thành các đầu ra giống hệt nhau. Việc sử dụng lại một khóa duy nhất trên toàn bộ cơ sở dữ liệu có nghĩa là việc giải mã khóa đó một lần sẽ giải mã được tất cả 153 triệu bản ghi. Schneier gọi đó là một trong những vụ rò rỉ mật khẩu tồi tệ nhất trong lịch sử. Giải pháp ở mọi lớp là chuyển sang sử dụng hàm băm chậm có thêm muối.
Muối vs tiêu: cuộc chiến hai lớp phòng thủ
Pepper là "người anh em" ít được biết đến hơn của salt. Khái niệm: một giá trị bí mật bổ sung, được áp dụng cho mọi mật khẩu mà ứng dụng xử lý, nhưng được lưu trữ bên ngoài cơ sở dữ liệu. Đó có thể là một biến môi trường, một mục nhập dịch vụ quản lý khóa, hoặc một khóa nằm trong HSM. Salt nằm cạnh mã băm dưới dạng văn bản thuần. Pepper thì không.
Mô hình tấn công là đánh cắp dữ liệu chỉ dựa trên cơ sở dữ liệu. Nếu kẻ tấn công chỉ đánh cắp cơ sở dữ liệu — thông qua tấn công SQL injection, sao lưu cấu hình sai hoặc rò rỉ dữ liệu — chúng có được salt và hash nhưng không có pepper. Không có pepper, chúng thậm chí không thể bắt đầu tấn công vét cạn vì mọi phỏng đoán hash của chúng đều thiếu bộ điều chỉnh bí mật toàn cục.
Một cách triển khai điển hình là chạy `argon2id(salt + password + pepper)` hoặc, cẩn thận hơn, tính toán `HMAC(pepper, password + salt)` trước rồi đưa kết quả vào Argon2id. OWASP khuyến nghị sử dụng pepper cho các hệ thống có giá trị cao nhưng thừa nhận sự đánh đổi: việc xoay vòng pepper gây khó khăn về mặt vận hành. Xoay vòng pepper có nghĩa là phải băm lại mật khẩu của mỗi người dùng khi đăng nhập lần tiếp theo, và nếu pepper bị mất mà không có bản sao lưu, mọi tài khoản sẽ không thể kiểm tra được. Hầu hết các ứng dụng dành cho người tiêu dùng bỏ qua pepper. Các ngân hàng, chính phủ và các hệ thống chăm sóc sức khỏe thường không làm vậy.
Công nghệ băm mật khẩu hiện đại năm 2026
Hướng dẫn lưu trữ mật khẩu năm 2025 của OWASP xếp hạng bốn thuật toán theo thứ tự ưu tiên. Salt được tích hợp sẵn trong tất cả các thuật toán này — bạn không cần tạo nó thủ công.
| Thuật toán | OWASP 2025 tối thiểu | Thông số kỹ thuật |
|---|---|---|
| Argon2id (ưu tiên) | m=19 MiB, t=2, p=1 | RFC 9106 (2021) |
| scrypt | N=2^17, r=8, p=1 | RFC 7914 (2016) |
| bcrypt (phiên bản cũ) | chi phí ≥ 10; giới hạn đầu vào 72 byte | Niels Provos, 1999 |
| PBKDF2-HMAC-SHA256 | 600.000 lần lặp | RFC 2898; Chỉ dành cho FIPS |
Argon2id rất khó nhớ, nghĩa là mỗi lần đoán không chỉ tốn chu kỳ CPU mà còn tốn một lượng RAM nhất định. Yêu cầu tối thiểu của OWASP là 19 MiB cho mỗi hàm băm, điều này có nghĩa là kẻ tấn công tự chế tạo ASIC cũng phải xây dựng rất nhiều bộ nhớ tốc độ cao, và bộ nhớ là phần đắt tiền nhất trong bất kỳ hệ thống nào. Biến thể "id" kết hợp Argon2i (chống tấn công kênh phụ) và Argon2d (chống tấn công GPU) bằng cách chạy Argon2i trong nửa đầu và Argon2d trong nửa sau.
scrypt ra đời trước Argon2id và hoạt động dựa trên nguyên tắc "khó nhớ" tương tự. bcrypt còn lâu đời hơn, đơn giản hơn và có giới hạn đầu vào cứng là 72 byte, đôi khi gây khó khăn cho các ứng dụng sử dụng mật khẩu dài — nên dùng băm trước bằng SHA-256 và mã hóa base64 nếu cần đầu vào dài hơn. PBKDF2 là lựa chọn chậm hơn nhưng tuân thủ FIPS; OWASP đã tăng số lần lặp của SHA-256 lên 600.000 vào năm 2023, từ mức 310.000.
Những thuật toán không thuộc danh sách này bao gồm: SHA-256 thông thường, SHA-512 thông thường, MD5, SHA-1 và bất kỳ hàm tùy chỉnh nào kết thúc bằng "+ salt". Tốc độ là yếu tố loại trừ. SHA-256 được thiết kế để hoạt động nhanh trên phần cứng thông thường. Điều đó hoàn toàn trái ngược với nhu cầu lưu trữ mật khẩu.
Những lỗi thường gặp khi thêm muối vào báo cáo kiểm toán thực tế
Các báo cáo về vi phạm bảo mật thực tế liên tục chỉ ra một số ít lỗi giống nhau.
Việc tái sử dụng một chuỗi muối cho mọi người dùng sẽ làm mất đi toàn bộ cơ chế – vấn đề bảng cầu vồng lại xuất hiện, chỉ với thêm một bước nữa. Sử dụng tên người dùng làm chuỗi muối còn tệ hơn, vì tên người dùng lặp lại trên các hệ thống và bảng cầu vồng có thể được tính toán trước cho những tên người dùng phổ biến. Độ dài chuỗi muối dưới mười sáu byte bắt đầu dẫn đến xung đột ở quy mô cơ sở người dùng lớn. Việc tạo chuỗi muối bằng một hàm ngẫu nhiên không mã hóa – `Math.random()`, `time(0)` mod một số nào đó, bộ tạo số ngẫu nhiên mặc định của ngôn ngữ – tạo ra các giá trị có thể dự đoán được, làm mất đi lợi ích của việc sử dụng chuỗi muối.
Một lỗi tinh vi hơn là lưu trữ muối (salt) trên một máy chủ khác "vì lý do bảo mật". Muối không phải là bí mật. Việc phân tán nó trên nhiều hệ thống sẽ làm tăng độ phức tạp trong vận hành mà không tăng thêm bất kỳ sức mạnh mã hóa nào. Hãy lưu trữ nó cùng hàng với hàm băm (hash). Các chuỗi PHC hiện đại đã tự động làm điều này cho bạn.
Vấn đề lớn nhất, theo các cuộc kiểm toán năm 2026, là việc sử dụng hàm băm SHA-256 thông thường cộng với salt và shipping. Salt ngăn chặn việc tạo bảng cầu vồng (rainbow tables). Tuy nhiên, nó không giải quyết được vấn đề hệ thống GPU thực hiện mười tỷ lần đoán mỗi giây đối với một tài khoản duy nhất. Giải pháp không phải là thêm salt thứ hai; mà là chuyển sang sử dụng thuật toán KDF chậm hơn như Argon2id.
Cuối cùng: các hàm băm cũ không dùng muối. Việc chuyển đổi là bắt buộc. Quy trình chuẩn là xác minh hàm băm cũ khi đăng nhập lần sau, băm lại bằng thuật toán hiện đại và ghi đè lên. Đối với những người dùng không bao giờ đăng nhập lại, hãy buộc họ đặt lại mật khẩu theo một lịch trình cố định.
Vì sao chỉ thêm muối thôi là chưa đủ
Việc thêm muối vào mật khẩu chỉ là một lớp bảo vệ, chứ không phải là một pháo đài. Nó chỉ chống lại một kiểu tấn công cụ thể — sử dụng bảng tính toán trước — và không tiết lộ gì về độ mạnh của mật khẩu gốc. Tấn công vét cạn vẫn hiệu quả với mật khẩu yếu. Tấn công nhồi nhét thông tin đăng nhập vẫn hiệu quả với mật khẩu được sử dụng lại. Tấn công lừa đảo qua email vẫn hiệu quả với bất kỳ mật khẩu nào.
Bảo mật mật khẩu thực sự vào năm 2026 sẽ có bốn lớp phòng vệ. Argon2id với chuỗi "salt" 16 byte cho mỗi người dùng xử lý việc lưu trữ. "Pepper" (tùy chọn nhưng hữu ích cho các hệ thống nhạy cảm) ngăn chặn việc đánh cắp dữ liệu chỉ trong cơ sở dữ liệu. Xác thực đa yếu tố ngăn chặn việc đánh cắp thông tin đăng nhập và hầu hết các cuộc tấn công lừa đảo. Giám sát vi phạm liên tục — các dịch vụ như Have I Been Pwned và API của nó — phát hiện ngay khi thông tin đăng nhập của người dùng bị lộ để có thể buộc họ phải đặt lại mật khẩu.
Nếu bỏ qua bất kỳ lớp bảo vệ nào trong số đó, kẻ tấn công cuối cùng cũng sẽ tìm ra lỗ hổng. Chỉ sử dụng salting, hoặc chỉ sử dụng một lớp phòng thủ duy nhất, chính là điểm yếu mà mọi cuộc phân tích sau tấn công trong thập kỷ qua đều chỉ ra.
