it-swarm-vi.com

Bảo mật https - mật khẩu nên được băm phía máy chủ hoặc phía máy khách?

Tôi đang xây dựng một ứng dụng web yêu cầu người dùng đăng nhập. Tất cả các giao tiếp đều đi qua https. Tôi đang sử dụng bcrypt để băm mật khẩu.

Tôi đang phải đối mặt với một vấn đề nan giải - Tôi đã từng nghĩ rằng an toàn hơn khi tạo mật khẩu băm phía máy khách (sử dụng JavaScript) và sau đó chỉ cần so sánh nó với hàm băm ở phía máy chủ DB. Nhưng tôi không chắc điều này có tốt hơn gửi mật khẩu văn bản đơn giản qua https và sau đó băm nó ở phía máy chủ.

Lý do của tôi là nếu kẻ tấn công có thể chặn lưu lượng https (= đọc mật khẩu văn bản gốc) thì anh ta cũng có thể thay đổi JavaScript để nó gửi mật khẩu văn bản gốc cùng với mật khẩu được băm - nơi anh ta có thể chặn nó.

Lý do chống lại băm phía khách hàng chỉ là dễ sử dụng. Nếu tôi băm phía máy khách, tôi cần sử dụng hai thư viện riêng để băm. Đây không phải là một vấn đề không thể vượt qua, nhưng nó là một phiền toái.

Có đạt được sự an toàn trong việc sử dụng băm phía khách hàng không? Tại sao?

Tôi cũng nên sử dụng thử thách-phản ứng?

CẬP NHẬT : điều tôi quan tâm nhất là điều này - các kỹ thuật này (băm phía khách hàng, phản hồi yêu cầu) có thêm bất kỳ mức tăng bảo mật đáng kể nào trong trường hợp https được sử dụng không? Nếu vậy, tại sao?

116
johndodo

Nếu bạn băm ở phía máy khách, mật khẩu được băm sẽ trở thành mật khẩu thực tế (với thuật toán băm không có gì khác hơn là một phương tiện để chuyển đổi một do người dùng nắm giữ mnemonic thành mật khẩu thực tế).

Điều này có nghĩa là bạn sẽ lưu trữ đầy đủ "văn bản thuần túy" mật khẩu (hàm băm) trong cơ sở dữ liệu và bạn sẽ mất tất cả lợi ích của việc băm ở vị trí đầu tiên.

Nếu bạn quyết định đi theo con đường này, bạn cũng có thể từ bỏ mọi hoạt động băm và chỉ cần truyền và lưu trữ mật khẩu thô của người dùng (điều này, tình cờ, tôi không đặc biệt khuyến nghị).

124
Nicole Calinoiu

Băm vào máy khách chỉ có ý nghĩa nếu bạn không tin tưởng máy chủ theo một cách nào đó và không muốn hiển thị mật khẩu "thực tế" (mật khẩu mà người dùng còn nhớ). Tại sao bạn không muốn hiển thị mật khẩu cho chính trang web mà mật khẩu đã sử dụng? Bởi vì bạn đã sử dụng lại mật khẩu ở nơi khác ! Bây giờ điều đó thường xấu, nhưng có một phiên bản tương đối an toàn được xuất hiện trong vô số các tiện ích mở rộng hoặc bookmarklets của trình duyệt như cái này hoặc cái đó (Tôi không bảo đảm chất lượng của chúng). Đây là những công cụ mà người dùng con người nhớ "mật khẩu chính", từ đó mật khẩu dành riêng cho trang web được tạo, sử dụng tên miền của trang web như một loại muối, để hai trang web riêng biệt có được mật khẩu riêng biệt.

Mặc dù kịch bản này có ý nghĩa, nhưng thực hiện nó với Javascript được gửi bởi chính máy chủ thì không. Thật vậy, điểm băm của phía máy khách mật khẩu là máy chủ có khả năng thù địch (ví dụ như bị tấn công bởi kẻ tấn công), và do đó, ít nhất là mã Javascript được gửi bởi máy chủ đó. Bạn không muốn nhập mật khẩu quý giá của mình vào một số Javascript thù địch ...


Một trường hợp khác cho băm phía khách hàng là về băm chậm. Vì mật khẩu, theo định nghĩa, yếu, bạn muốn cản trở tấn công từ điển . Bạn cho rằng kẻ xấu đã có một bản sao của cơ sở dữ liệu máy chủ và sẽ "thử mật khẩu" trên máy của chính mình (xem bài đăng trên blog này để thảo luận về điều này). Để làm chậm đối thủ, bạn sử dụng quy trình băm vốn đã chậm (chẳng hạn như bcrypt ), nhưng điều này sẽ khiến việc xử lý chậm đối với mọi người, kể cả máy chủ. Để giúp máy chủ, bạn có thể muốn giảm tải một số công việc trên máy khách, do đó, ít nhất là một phần của nó trong một số mã Javascript chạy trong trình duyệt máy khách ...

Thật không may, Javascript rất chậm với loại công việc này (thường chậm hơn 20 đến 100 lần so với mã C đàng hoàng) và hệ thống máy khách sẽ không thể đóng góp một phần đáng kể vào nỗ lực băm. Ý tưởng là âm thanh nhưng sẽ phải chờ công nghệ tốt hơn (nó sẽ hoạt động với a Java client, mặc dù: với một JVM phong nha, được tối ưu hóa Java chậm hơn khoảng 2 đến 4 lần so với mã C được tối ưu hóa, cho công việc băm).


Tóm lại, không có trường hợp nào thực sự tốt để thực hiện băm mật khẩu phía máy khách, từ mã Javascript được gửi bởi chính máy chủ. Chỉ cần gửi mật khẩu "nguyên trạng" đến máy chủ thông qua đường hầm HTTPS (trang đăng nhập, URL đích của biểu mẫu và bất kỳ trang nào được bảo vệ bởi mật khẩu, sẽ tất cả được phục vụ qua SSL, nếu không, bạn có nhiều vấn đề bảo mật cấp bách hơn là sử dụng mật khẩu).

32
Thomas Pornin

Tôi thấy tất cả các mối quan tâm của bạn có vẻ tốt, nhưng khuyến nghị của tôi sẽ là làm phía máy chủ.

Luôn có một cơ hội khá lớn rằng người dùng sẽ mở khóa thiết bị đầu cuối của họ, cho phép thao tác. Và cũng; nếu logic băm của bạn là phía máy khách, bạn sẽ phơi bày nó.

Một tùy chọn khác là tạo mật khẩu phía máy chủ; sau đó bạn không gửi mật khẩu rõ ràng. Nhưng bạn vẫn cần truyền đạt mật khẩu cho người dùng. Và vì hầu hết người dùng vẫn không sử dụng email được mã hóa, tôi cho rằng điều đó kém an toàn hơn.

Tôi đã thấy các giải pháp để gửi mật khẩu thông qua một đường hầm được mã hóa đến điện thoại di động; nhưng tôi nghi ngờ bảo mật tốt hơn SSL. Có lẽ ai đó có thể chứng minh/bác bỏ điều này?

11
rmorero

Băm phía máy chủ rất quan trọng vì tất cả các câu trả lời khác đã chỉ ra, nhưng tôi muốn thêm rằng băm phía máy khách sẽ là một tính năng bảo mật Nice ngoài ra cho băm phía máy chủ.

Băm phía khách hàng có lợi ích trong các trường hợp sau:

  1. Bảo vệ mật khẩu của người dùng khi máy chủ bị xâm nhập. I E. nếu máy khách không bị xâm phạm, nhưng máy chủ thì, nếu máy khách bẻ khóa mật khẩu, máy chủ vẫn có thể truy cập vào một hệ thống, nhưng bạn đã bảo vệ mật khẩu của người dùng, điều quan trọng nếu họ sử dụng mật khẩu đó ở nơi khác.
  2. Bảo vệ mật khẩu của người dùng khi người dùng nghĩ rằng họ đang đăng nhập vào một máy chủ nhưng họ thực sự đăng nhập vào một máy chủ khác (lỗi người dùng). Ví dụ: nếu tôi có hai tài khoản ngân hàng và tôi vô tình nhập một mật khẩu ngân hàng của tôi vào trang web của ngân hàng sai, nếu ngân hàng băm mật khẩu phía khách hàng mà ngân hàng đó sẽ không biết mật khẩu của ngân hàng khác của tôi. Tôi nghĩ rằng đó là một điều "lịch sự" cần làm để băm phía khách hàng để mật khẩu văn bản đơn giản của họ không bao giờ được truyền qua dây.

Chủ yếu là nó thể hiện sự tôn trọng đối với mật khẩu của người dùng. Người dùng đang chia sẻ một bí mật có thể không dành riêng cho phần mềm của bạn, vì vậy nếu bạn tôn trọng bí mật đó, bạn nên làm mọi thứ trong khả năng của mình để bảo vệ nó.

10
Samuel

Nếu bạn đang ở trong đường hầm HTTPS, mật khẩu hoặc hàm băm phải được bảo mật khỏi sự giám sát Ethernet.

Về phía khách hàng, có lẽ bạn có thể muối băm với id phiên.
[.__.] Điều này có thể khó hơn đối với Javascript độc hại để mô phỏng.

2
bua

Bạn có thể làm cả hai, bạn băm nó tại máy khách để nếu kẻ tấn công có thể vượt qua bảo mật https, họ sẽ không thể thấy mật khẩu văn bản đơn giản. Sau đó băm nó một lần nữa tại máy chủ để nếu kẻ tấn công lấy được mật khẩu được lưu trong máy chủ, anh ta không thể gửi nó đến máy chủ và lấy quyền truy cập vào mật khẩu.

1
nat that

Băm mật khẩu phía máy khách sẽ yêu cầu Javascript. Một số người vô hiệu hóa Javascript trên trình duyệt của họ. Bạn phải xử lý tình huống này.

Tôi đã thấy phần mềm diễn đàn thực hiện băm mật khẩu phía máy khách và gửi hàm băm khi đăng nhập nếu có thể, nếu không thì mật khẩu được gửi bằng văn bản thuần túy. Vì vậy, nó hoạt động trong cả hai tình huống.

Gửi mật khẩu rõ ràng không phải là mối quan tâm chính nếu bạn sẽ sử dụng https. Lý tưởng nhất là máy chủ của bạn nên từ chối phục vụ các trang trong http để tránh người đàn ông trong cuộc tấn công giữa. Lý do là: kẻ tấn công có thể buộc 'hạ cấp' kết nối của bạn từ https xuống http và bắt đầu đánh hơi lưu lượng truy cập (ví dụ: với một công cụ như Dải SSL).

1
Anonymous

Câu trả lời được chấp nhận của @ Nicole Calinoiu tất nhiên là đúng nhưng có thể khó hiểu ngay từ đầu.

Vấn đề là mật khẩu nên được băm trên máy chủ để kẻ độc hại không thể sử dụng băm mà anh ta đã hack từ cơ sở dữ liệu từ máy chủ để có quyền truy cập vào tài khoản hoặc dữ liệu của bạn.

Như đã nói nếu bạn băm ở phía máy khách và back-end hỗ trợ điều đó, thì băm trở thành mật khẩu của bạn và nếu băm bị đánh cắp thông qua một vụ hack, thì hacker có mật khẩu.

@ Thomas Pornin câu trả lời cũng đã đưa ra một điểm rất hay tại sao bạn muốn băm mật khẩu trên máy khách, nhưng điều mà anh ta mô tả trong câu chuyện đầu tiên của mình chỉ có thể được thực hiện nếu phần cuối của máy chủ hỗ trợ xử lý mật khẩu băm (nghĩa là không băm mật khẩu nếu đã băm, nhưng ai đó cố gắng hỗ trợ một cái gì đó rất khó xảy ra ), mà hầu hết thời gian sẽ không phải là trường hợp tôi đoán. Câu chuyện thứ hai của anh ấy rất hay.

0
Ini