Sau khi đọc nội dung bài viết băm mật khẩu đúng cách dán của anh ấy thaidn, mình nhớ lại cơ hội bản thân mới ra trường, cũng đã từng nghĩ về sự việc này (thời điểm đó bản thân khá mê thích môn Bảo Mật Thông Tin lên trên trường) tuy thế không lúc nào hiểu kĩ càng. Chỉ biết là ko nên:

Lưu password sinh sống dạng plain-text.Hash với một thuật tân oán hash mạnh bạo, tránh việc xài MD5, SHA-1 ...Hash với salt.

Bạn đang xem: Bcrypt là gì

Chỉ hiểu rõ rằng nên nên làm cho nắm, cơ mà thiếu hiểu biết tại vì sao lại như thế cùng một số trong những câu hỏi không giống cũng không vấn đáp được như:

Password user trình lên, yêu cầu hash sinh hoạt client tốt sinh hoạt server.Salternative text đề xuất lưu ở chỗ nào.Salternative text gồm phải duy trì kín đáo giỏi không?Salt phổ biến đến toàn bộ, giỏi salternative text riêng biệt cho từng user?

Hôm nay, mình ra quyết định đi tìm câu trả lời mang lại đầy đủ sự việc mình thắc mắc, núm bởi mang định nó đúng.

1. Tại sao tránh việc lưu giữ plain-text, encrypt hoặc sử dụng MD5, SHA-1

Nếu lưu giữ plain-text, database bị hack, SQL-injection, password user chìa ra theo một giải pháp cấp thiết dễ dàng hơn để đánh cắp.

Nếu mã hóa 2 chiều, đã luôn gồm một phương pháp để giải mã bằng một chìa-khóa như thế nào đó, vẫn cần tìm cách giữ chìa-khóa một giải pháp bình an.

MD5 và SHA-1 được chứng tỏ tất cả đụng độ, tức thị 2 password khác biệt, Lúc hash bằng MD5 hoặc SHA-1 rất có thể ra cùng một chuỗi.

2. Tại sao đề nghị salt

Ta sẽ biết, hash algorithm là one-way-function, có nghĩa là bắt buộc suy ngược trực tiếp ra password giả dụ có hash_value (không giống cùng với mã hóa, rất có thể lời giải thông qua chìa-khóa).

Tuy nhiên vẫn đang còn cách để trường đoản cú hash_value hoàn toàn có thể suy gián tiếp ra được password ví dụ brute-force attach, dictionary attach -> điểm thông thường là ta cần thử với đoán password các lần cho tới khi đúng cái bắt buộc tìm.

Một phương pháp không giống sẽ là ta hoàn toàn có thể tính toán thù trước quý hiếm hash của tất cả các ngôi trường hợp với của tất cả các thuật tân oán -> bí quyết này khó khăn, tốn thời hạn, nhưng lại hiện nay với tốc độ tính tân oán của máy tính, ta vẫn rất có thể làm được. Bảng tàng trữ password + hash_value của password Call là Rainbow Table, có thể trường đoản cú chế tạo ra hoặc mua một vài phiên bản miễn phí hoặc trả tiền để sở hữ. Từ bây giờ trường hợp ta có hash_value ta hoàn toàn có thể mapping để suy ra được password.

Tuy nhiên nếu như ta chỉ hash từng password, ta gặp gỡ vấn đề đó là:

2 password giống nhau (user vô tình trùng password) thì chuỗi hash(password) vẫn tương đương nhau.User cố ý đặt password đơn giản và dễ dàng cùng thông dụng (ví dụ password dễ dàng nhớ mang lại user mà lại dễ tra ngược.

Và trường hợp chỉ hash password thì nếu mất hash_value, hoàn toàn có thể tra vào rainbow table để đưa ra được password của người tiêu dùng.

Giờ ta thử cố gắng bởi vì hash(password) ta sẽ hash(salternative text + password):

Từ md5(123456)

id | hash_md5 |---------------------------------------1 | e10adc3949ba59abbe56e057f20f883e |Thành md5(7nWZLcCK0vsPzIM + 123456)

id | hash_md5 | salternative text |---------------------------------------------------------1 | 0510210d4b370165658bdc0d0b005244 | 7nWZLcCK0vsPzIM |Giờ đưa sử, ta mất bảng tài liệu gồm hash_md5, salternative text, kẻ tiến công sẽ bắt buộc tính toán thù lại rainbow table của tất cả các trường hòa hợp cộng cùng với salternative text. Nếu salternative text là random cho từng user, kẻ tấn công vẫn nên tính tân oán toàn thể trường hòa hợp cộng với riêng rẽ từng salternative text mang đến toàn bộ user.

giá thành đến 2 phxay tính trên là vô cùng lớn cùng tốn không ít thời hạn nhằm tiến hành. Vậy Tóm lại mục đích của salt và random-salternative text là:

Bảo vệ user của cả khi user dùng password phổ biến với password không khỏe mạnh vì chưng user cấp thiết ghi nhớ được những password tinh vi nhưng lại vận tốc tính tân oán của máy tính thì càng ngày càng nhanh hao.Tạo ra nhiều ngân sách tính tân oán, kẻ tiến công không thể tính toán thù trước rainbow table.

=> Ta trả lời được 3 câu hỏi:

Salternative text có thể giữ vào database, cùng với hash_value.Không bắt buộc tìm kiếm bí quyết giữ kín salt, nhưng cũng chớ từ ý công khai salt.Nhưng sẽ phải random salt mang đến từng user.

Xem thêm: Ngành Diêm Nghiệp Là Gì - Định Nghĩa Về Diêm Nghiệp

3. Hash sinh sống đâu?

Giờ giả sử hash(password) ở client-side thì sự việc là gì?

Biết được thuật toán dùng làm hash.Salt đang yêu cầu hình thành sinh hoạt client, vì chưng ta bắt buộc hash password cùng với salternative text (hash(salt + password)), với db chỉ lưu tác dụng hash, ko lưu salt.Nhưng nếu salt xuất hiện sinh hoạt client cùng salt random thì làm sao nhằm compare cùng với hash_value trong database? Vì lần chứng thực cho tới, salternative text đang lại random cùng vẫn không giống cùng với tác dụng trong database -> salternative text đề nghị duy nhất đến toàn bộ những ngôi trường đúng theo.Hoặc salternative text có thể lưu lại sống DB, mà lại VPS yêu cầu gửi salternative text về trước đến user trước lúc tiến hành hash -> dễ dãi hiểu rằng salternative text hơn.

Nhìn sơ thì thấy vấn đề cần sử dụng độc nhất vô nhị một salternative text đã cản lại vấn đề ở mục số 2. Vậy tiến trình xác thực đúng là như thế nào?

User đang gửi plain-text password lên hệ thống và over HTTPs.Server đã kiểm tra vào database mang ra salt của user đó, cùng chuỗi ta được salt + password.Thực hiện nay hash(salternative text + password) bên trên server side.Compare công dụng trên cùng với hash_md5 trong database.

4. Tại sao sử dụng bcrypt nỗ lực cho SHA-512

Kết quả của SHA-512 gồm độ nhiều năm 128 kí trường đoản cú, độ lâu năm của key là 64 bytes. Trông có vẻ như cũng rất chắc chắn là, vậy tại sao OWASPhường recommend sử dụng PBKDF2, bcrypt hoặc scrypt hơn là SHA2?

SHA2 là hash algorithm (vớ nhiên), nó được thiết kế với mục tiêu là vận tốc, với các CPU tân tiến, hoàn toàn có thể generate hàng tỷ tác dụng trên giây. Nếu dùng một thuật toán thù có vận tốc như SHA2 Tức là các bạn vẫn lấy lợi điểm cho tới cho kẻ tiến công brute-force. Thuật toán nhanh khô + cấu hình server to gan, câu hỏi brute-force càng trở lên gấp rút hơn.

Trong lúc ấy, bcrypt được Điện thoại tư vấn là slow-hash algorithm, bcrypt() mất 100ms để tính tân oán ra chuỗi hash, chậm rì rì hơn 10.000 lần so với sha1().

Tức là vẫn đạt được mục đích hash mà lại bớt tgọi nguy cơ tiến công brute-force.

Tóm lại: SHA-512 không hẳn là một trong những thuật tân oán yếu hèn, nhưng mà sự việc là SHA-512 không phù hợp mang đến bài toán hash password. Nếu đề nghị hash password thì ta buộc phải dùng các thuật toán thù slow hash nlỗi PBKDF2, bcrypt và scrypt.

5. Tại sao đề nghị Pepper?

Một thực tiễn là nếu khách hàng chỉ có "muối" nhưng mà không tồn tại "tiêu", ăn giết mổ con gà luộc sẽ không ngon :v. Giả sử, database bạn chạy RAID-1, một ổ cứng lỗi và cần thay như là 1 ổ cứng bắt đầu. Nhưng nhỏng ta biết, đĩa bị lỗi là mirror của đĩa còn lại, chúng ta buộc phải tiêu diệt ổ cứng hư kia giả dụ không người nào kia hoàn toàn có thể lục thùng rác rưởi và tái chế tác lại một phần tài liệu vào đĩa hỏng kia.

Xin để ý, bạn cần wipe trước khi bỏ vứt một ổ cứng bao gồm tài liệu mặc dù cá thể xuất xắc VPS, tuy nhiên đĩa bị sốc điện, bad-sector thì wipe cũng chưa đầy đủ an ninh, tốt nhất nên ngiền ra buồn bực.

Dù random-salternative text đang làm cho tăng chi phí tạo ra rainbow table nhưng đời lần chần đâu nhưng mà lần, kẻ tiến công luôn bao hàm hễ lực ngoạn mục nhằm dành được mẫu bạn thích. Giả sử kẻ tấn công có một khôn cùng hết sức máy tính xách tay và một mirror ổ cứng hỏng lục tự một chiếc thùng rác rưởi làm sao đó. Với khôn cùng laptop kia, ta gồm rainbow-table để tra ngược ra password đề nghị tìm kiếm.

Vậy làm thế nào nhằm sút thiểu nguy cơ trên? Ngulặng tắc là không vứt tất cả trứng vào một giỏ, sẽ là pepper. Pepper là 1 trong những chuỗi tương tự như nhỏng salt, nhưng mà khác hoàn toàn là ta yêu cầu giữ bí mật pepper, lưu tại một nơi khác kế bên database, cùng ko buộc phải pepper-per-user, chỉ cần 1 pepper là đủ.

Từ

hash(salt + password)Thành

hash(pepper + salt + password)Ta bắt buộc lưu pepper ngơi nghỉ application hoặc ở một service khác, nếu database bị compromise, thì kẻ tiến công cũng không tồn tại pepper nhằm tạo ra rainbow-table.

6. Bonus

*

Trong Khi tra cứu câu trả lời để viết bài này, bản thân tìm được một bài bác blog của dropbox nói về cách chúng ta lưu password ra sao. Thấy tất cả 2 điểm hơi hay đề xuất hy vọng nói thêm.

Trước khi hash password với salt-per-user, chúng ta tất cả SHA512(password) trước để thế định độ dài của input-password. Theo Dropbox thì Việc này giải quyết 2 issues của bcryptMột số implementation của bcrypt giảm đầu vào còn 72 bytes.Một số implementation khác của bcrypt thì không giảm nguồn vào cơ mà dẫn đến một vấn đề không giống là DoS attachồng cũng chính vì cho phép độ dài mật khẩu tùy ý.Dropbox cũng có global pepper tuy vậy cố gắng vày sử dụng nó nhằm hash thì họ encrypt. Tức là nuốm bởi hash(pepper + salt + password) thì họ AES256(salt + password) + global-pepper-key. Theo nhỏng chúng ta lý giải thì pepper là một trong những lớp che chở sâu rộng và lưu trữ ở một địa điểm riêng lẻ. Nhưng đồng nghĩa tương quan với việc là địa điểm lưu trữ pepper vẫn có thể bị compromise, với Lúc bị compromise thì vấn đề rotate key không thuận lợi. Dùng pepper để encrypt vẫn giành được mục đích bảo mật thông tin tương tự như tuy vậy thêm kỹ năng rotate key lúc bị compromise.

7. Migrate

Sau Lúc viết bài bác này, bạn

Bài viết liên quan

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *