Bcrypt là gì

      15

Sau Khi đọc bài viết băm password đúng cách dán của anh ý thaidn, bản thân ghi nhớ lại lúc mình mới ra trường, cũng đã từng nghĩ về vấn đề này (thời gian kia mình khá đam mê môn Bảo Mật Thông Tin lên trên trường) dẫu vậy chưa khi nào phát âm tỉ mỉ. Chỉ biết là không nên:

Lưu password ngơi nghỉ dạng plain-text.Hash với cùng 1 thuật toán hash khỏe mạnh, tránh việc xài MD5, SHA-1 ...Hash cùng với salt.

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

Chỉ hiểu rằng cần buộc phải làm nạm, tuy nhiên không hiểu biết nhiều tại sao lại như thế và một vài câu hỏi khác cũng chưa trả lời được như:

Password user gửi lên, phải hash sinh sống client giỏi làm việc server.Salt đề xuất lưu ở đâu.Salt tất cả yêu cầu duy trì bí mật xuất xắc không?Salt chung mang đến toàn bộ, hay salt riêng đến từng user?

Hôm nay, mình đưa ra quyết định đi kiếm câu vấn đáp mang đến đa số sự việc bản thân vướng mắc, cố kỉnh vì chưng mặc định nó đúng.

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

Nếu lưu giữ plain-text, database bị haông xã, SQL-injection, password user chìa ra theo một phương pháp quan yếu thuận lợi hơn nhằm đánh cắp.

Nếu mã hóa 2D, đã luôn luôn gồm một cách để giải mã bởi một chìa-khóa làm sao kia, vẫn đề nghị tìm kiếm phương pháp lưu lại chìa-khóa một giải pháp bình yên.

MD5 và SHA-1 được minh chứng có đụng độ, nghĩa là 2 password không giống nhau, lúc hash bằng MD5 hoặc SHA-1 có thể ra cùng một chuỗi.

2. Tại sao yêu cầu salt

Ta vẫn biết, hash algorithm là one-way-function, tức là không thể suy ngược thẳng ra password trường hợp gồm hash_value (khác 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 có phương pháp để trường đoản cú hash_value rất có thể suy loại gián tiếp ra được password ví dụ brute-force attach, dictionary attach -> điểm chung là ta đề xuất thử với đoán password những lần cho tới lúc đúng loại buộc phải kiếm tìm.

Một bí quyết khác chính là ta rất có thể tính toán thù trước quý giá hash của tất cả các trường thích hợp với của tất cả những thuật toán thù -> biện pháp này nặng nề, tốn thời gian, cơ mà hiện thời với vận tốc tính toán của dòng sản phẩm tính, ta vẫn có thể có tác dụng được. Bảng lưu trữ password + hash_value của password Gọi là Rainbow Table, hoàn toàn có thể tự tạo nên hoặc cài một trong những bạn dạng miễn mức giá hoặc trả tiền để sở hữ. Từ bây chừ nếu như ta bao gồm hash_value ta hoàn toàn có thể mapping nhằm suy ra được password.

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

2 password như là nhau (user vô tình trùng password) thì chuỗi hash(password) đang kiểu như nhau.User cố tình đặt password đơn giản và thịnh hành (ví dụ password dễ dàng ghi nhớ cho user nhưng dễ dàng tra ngược.

Và nếu như chỉ hash password thì nếu mất hash_value, rất có thể tra trong rainbow table để tìm thấy được password của người tiêu dùng.

Giờ ta demo cụ vì chưng hash(password) ta đã hash(salternative text + password):

Từ md5(123456)

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

id | hash_md5 | salt |---------------------------------------------------------1 | 0510210d4b370165658bdc0d0b005244 | 7nWZLcCK0vsPzIM |Giờ đưa sử, ta mất bảng dữ liệu có hash_md5, salternative text, kẻ tiến công đang nên tính toán thù lại rainbow table của toàn bộ những trường hợp cùng với salternative text. Nếu salternative text là random mang đến từng user, kẻ tiến công sẽ đề nghị tính toán toàn bộ trường hợp cùng với riêng biệt từng salternative text mang lại tổng thể user.

giá thành mang lại 2 phnghiền tính trên là hết sức bự với tốn rất nhiều thời gian nhằm tiến hành. Vậy kết luận mục tiêu của salt với random-salternative text là:

Bảo vệ user tất cả khi user sử dụng password phổ cập và password không khỏe khoắn vì chưng user cấp thiết lưu giữ được những password phức tạp tuy nhiên vận tốc tính toán của sản phẩm tính thì ngày càng nkhô giòn.Tạo ra nhiều chi phí tính tân oán, kẻ tấn công quan trọng tính toán trước rainbow table.

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

Salternative text rất có thể lưu giữ vào database, cùng với hash_value.Không buộc phải tìm kiếm cách duy trì bí mật salt, cơ mà cũng chớ từ bỏ ý công khai salternative text.Nhưng cần phải random salt cho từng user.

Xem thêm: Hướng Dẫn Cách Thu Hồi Email Đã Gửi Gmail Trên Điện Thoại Và Máy Tính, Pc

3. Hash sinh hoạt đâu?

Giờ mang sử hash(password) ở client-side thì vấn đề là gì?

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

Nhìn sơ thì thấy Việc sử dụng độc nhất vô nhị một salt đã chống lại luận điểm sinh sống mục số 2. Vậy quy trình xác thực và đúng là như thế nào?

User đang gửi plain-text password lên hệ thống và over HTTPs.Server vẫn bình chọn trong database mang ra salternative text của user đó, cộng chuỗi ta được salt + password.Thực hiện tại hash(salternative text + password) trên VPS side.Compare công dụng trên cùng với hash_md5 trong database.

4. Tại sao dùng bcrypt nắm đến SHA-512

Kết trái của SHA-512 có độ lâu năm 128 kí từ, độ nhiều năm của key là 64 bytes. Trông có vẻ cũng tương đối chắc chắn rằng, vậy tại vì sao OWASP recommend áp dụng PBKDF2, bcrypt hoặc scrypt hơn là SHA2?

SHA2 là hash algorithm (tất nhiên), nó được thiết kế cùng với phương châm là vận tốc, với các CPU văn minh, rất có thể generate hàng ngàn kết quả bên trên giây. Nếu cần sử dụng một thuật toán thù tất cả tốc độ nhỏng SHA2 tức là các bạn vẫn đem lợi điểm tới cho kẻ tiến công brute-force. Thuật toán thù nkhô giòn + cấu hình hệ thống mạnh bạo, câu hỏi brute-force càng trsống lên nhanh chóng hơn.

Trong khi đó, bcrypt được điện thoại tư vấn là slow-hash algorithm, bcrypt() mất 100ms để tính toán ra chuỗi hash, chậm rãi rộng 10.000 lần đối với sha1().

có nghĩa là vẫn đạt được mục đích hash dẫu vậy bớt tđọc nguy cơ tiềm ẩn tấn công brute-force.

Tóm lại: SHA-512 không phải là 1 thuật tân oán yếu, nhưng mà vấn đề là SHA-512 ko tương xứng mang lại bài toán hash password. Nếu đề xuất hash password thì ta cần dùng các thuật tân oán slow hash như PBKDF2, bcrypt và scrypt.

5. Tại sao cần Pepper?

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

Xin lưu ý, bạn cần wipe trước khi bỏ quăng quật một ổ cứng tất cả dữ liệu mặc dù cá thể hay server, tuy nhiên đĩa bị sốc năng lượng điện, bad-sector thì wipe cũng chưa đầy đủ bình an, cực tốt phải ngiền ra buồn chán.

Dù random-salt vẫn có tác dụng tăng chi phí tạo ra rainbow table mà lại đời đo đắn đâu cơ mà lần, kẻ tiến công luôn luôn gồm có động lực ngoạn mục để giành được cái mình thích. Giả sử kẻ tiến công có một cực kỳ khôn cùng máy vi tính với một mirror ổ cứng lỗi lục trường đoản cú một cái thùng rác rến như thế nào kia. Với hết sức máy tính đó, ta gồm rainbow-table nhằm tra ngược ra password phải search.

Vậy làm thế nào để sút tgọi nguy hại trên? Nguyên tắc là ko vứt tất cả trứng trong một giỏ, sẽ là pepper. Pepper là 1 trong những chuỗi tương tự nlỗi salternative text, mà lại khác hoàn toàn là ta yêu cầu giữ lại kín đáo pepper, lưu ở một chỗ khác quanh đó database, cùng không yêu cầu pepper-per-user, chỉ cần 1 pepper là đầy đủ.

Từ

hash(salt + password)Thành

hash(pepper + salt + password)Ta phải lưu pepper nghỉ ngơi application hoặc tại một service khác, trường hợp database bị compromise, thì kẻ tấn công cũng không tồn tại pepper nhằm tạo ra rainbow-table.

6. Bonus

*

Trong Lúc tìm câu trả lời để viết bài xích này, mình tìm được một bài blog của dropbox nói về cách chúng ta lưu giữ password ra sao. Thấy bao gồm 2 điểm khá giỏi bắt buộc ý muốn nói thêm.

Xem thêm: Tin Tức Sự Kiện, Hình Ảnh Mới Nhất Về Người Cổ Xưa, Người Cổ Đại

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

7. Migrate

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

Chuyên mục: Tin Tức