Tại sao hầu như không có trang web nào băm mật khẩu trong máy khách trước khi gửi (và băm chúng một lần nữa trên máy chủ), như để bảo vệ thành phố chống lại việc sử dụng lại mật khẩu?

Có nhiều trang web trên Internet yêu cầu thông tin đăng nhập và cách duy nhất để bảo vệ chống lại việc sử dụng lại mật khẩu là "lời hứa" rằng mật khẩu được băm trên máy chủ, điều này không phải lúc nào cũng đúng.

Vì vậy, tôi tự hỏi, làm thế nào là khó khăn để làm cho một trang web băm mật khẩu trong máy khách (với Javascript), trước khi gửi chúng đến máy chủ, nơi chúng sẽ được băm lại? Về lý thuyết, điều này không cung cấp thêm bất kỳ sự bảo mật nào, nhưng trong thực tế, điều này có thể được sử dụng để bảo vệ chống lại "các trang web lừa đảo" không băm mật khẩu của bạn trong máy chủ.

Tại sao nó không được sử dụng? Bởi vì đó là rất nhiều công việc làm thêm để đạt được không. Một hệ thống như vậy sẽ không an toàn hơn. Nó thậm chí có thể kém an toàn hơn vì nó mang lại ấn tượng sai về việc bảo mật hơn, khiến người dùng áp dụng các thực tiễn kém an toàn hơn (như sử dụng lại mật khẩu, mật khẩu từ điển, v.v.).

Về lý thuyết, điều này không cung cấp thêm bất kỳ sự bảo mật nào, nhưng trong thực tế, điều này có thể được sử dụng để bảo vệ chống lại "các trang web lừa đảo" không băm mật khẩu của bạn trong máy chủ.

Làm thế nào chính xác điều này bảo vệ bạn? Có vẻ như tất cả những gì bạn muốn làm là băm mật khẩu băm là vô nghĩa. Bởi vì mật khẩu băm sau đó sẽ trở thành mật khẩu.

Có nhiều trang web trên Internet yêu cầu thông tin đăng nhập và cách duy nhất để bảo vệ chống lại việc sử dụng lại mật khẩu là "lời hứa" rằng mật khẩu được băm trên máy chủ, điều này không phải lúc nào cũng đúng.

Làm thế nào về việc không sử dụng cùng một mật khẩu cho nhiều hơn một trang web. Lý do các trang web băm mật khẩu trong lý thuyết là để ngăn truy cập vào tài khoản của bạn nếu HỌ bị xâm phạm. Sử dụng cùng một mật khẩu cho nhiều trang web chỉ là ngu ngốc.

Nếu bạn đã sử dụng javascript, tất cả "hacker" sẽ phải làm là, sử dụng cùng một phương pháp trên mật khẩu băm-băm. Khi bạn đã có thông tin băm, chỉ cần có thời gian để tính toán mật khẩu-> cùng một hàm băm trong cơ sở dữ liệu là yếu tố ngăn chặn quyền truy cập vào tài khoản.

Bởi vì nó sẽ thêm ít hoặc không có giá trị. Lý do băm là nếu cơ sở dữ liệu của bạn bị hack, tin tặc sẽ không có danh sách mật khẩu hợp lệ, chỉ băm. Do đó, họ không thể mạo danh bất kỳ người dùng nào. Hệ thống của bạn không có kiến ​​thức về mật khẩu.

Bảo mật đến từ chứng chỉ SSL cộng với một số hình thức xác thực. Tôi muốn người dùng của mình cung cấp mật khẩu để tôi có thể tính toán hàm băm từ nó.

Ngoài ra, thuật toán băm sẽ ở trên máy chủ trong một khu vực an toàn hơn. Đưa nó vào máy khách, thật dễ dàng để lấy mã nguồn cho Javascript, ngay cả khi các tệp script được tham chiếu ẩn của nó.

Giải pháp đơn giản hơn thế. Giấy chứng nhận khách hàng. Tôi tạo chứng chỉ ứng dụng khách trên máy của mình. Khi tôi đăng ký với một trang web, chúng tôi bắt tay bằng chứng chỉ ứng dụng khách của tôi và chứng chỉ của máy chủ.

Không có mật khẩu nào được trao đổi và ngay cả khi ai đó hack cơ sở dữ liệu, tất cả những gì họ sẽ có là khóa công khai của chứng chỉ ứng dụng khách của tôi (cần được máy chủ lưu trữ và mã hóa để tăng mức độ bảo mật).

Chứng chỉ ứng dụng khách có thể được lưu trữ trên thẻ thông minh (và được tải lên kho tiền trực tuyến an toàn bằng mật khẩu chính).

Cái hay của tất cả là nó loại bỏ khái niệm lừa đảo ... bạn không bao giờ nhập mật khẩu vào một trang web, bạn chỉ bắt tay với trang web đó. Tất cả những gì họ nhận được là khóa công khai của bạn vô dụng nếu không có khóa riêng. Nhạy cảm duy nhất là tìm thấy một vụ va chạm trong khi bắt tay và điều đó sẽ chỉ hoạt động một lần trên một trang web duy nhất.

Microsoft đã cố gắng cung cấp một cái gì đó như thế này trong Windows với Thẻ không gian và sau đó đã gửi nó dưới dạng một tiêu chuẩn mở. OAuth có phần giống nhau nhưng nó dựa vào một "bên phát hành" trung gian. InfoCards mặt khác có thể được ban hành. Đó là giải pháp thực sự cho vấn đề mật khẩu ... xóa hoàn toàn mật khẩu.

OAuth là một bước đi đúng hướng mặc dù.

hầu hết các câu trả lời ở đây dường như hoàn toàn bỏ lỡ điểm băm mật khẩu phía máy khách.

vấn đề không phải là bảo mật truy cập vào máy chủ mà bạn đang đăng nhập, vì việc chặn băm không an toàn hơn việc chặn mật khẩu văn bản đơn giản.

vấn đề thực sự là bảo mật mật khẩu của người dùng , thường có giá trị hơn nhiều so với truy cập đăng nhập trang cá nhân vì hầu hết người dùng sẽ sử dụng lại mật khẩu của họ cho nhiều trang web (họ không nên nhưng thực tế là họ không nên xóa nó ).

ssl rất tốt để bảo vệ chống lại các cuộc tấn công của mitm, nhưng nếu một ứng dụng đăng nhập bị xâm phạm trên máy chủ, ssl sẽ không bảo vệ người dùng của bạn. nếu ai đó có quyền truy cập độc hại vào máy chủ web, họ có thể sẽ chặn mật khẩu ở dạng văn bản đơn giản vì trong hầu hết các trường hợp, mật khẩu chỉ được băm bởi tập lệnh trên máy chủ. sau đó kẻ tấn công có thể thử các mật khẩu đó trên các trang web khác (thường có giá trị hơn) bằng cách sử dụng tên người dùng tương tự.

bảo mật là phòng thủ theo chiều sâu và băm phía khách hàng chỉ cần thêm một lớp khác. hãy nhớ rằng trong khi bảo vệ quyền truy cập vào trang web của riêng bạn là rất quan trọng, thì việc bảo vệ bí mật mật khẩu của người dùng của bạn lại quan trọng hơn nhiều vì việc sử dụng lại mật khẩu trên các trang web khác.

Điều này là hoàn toàn có thể, và thực sự bạn không cần phải đợi một trang web.

Hãy xem SuperGenPass . Nó là một bookmarklet.

Nó chỉ đơn giản là nhận ra các trường mật khẩu, nối các nội dung bạn nhập với tên miền của trang web, băm nó, xé nó một chút để chỉ nhận các ký tự "được thừa nhận" trong mật khẩu và chỉ sau đó mật khẩu băm của bạn được gửi trên dây.

Bằng cách sử dụng tên miền trang web trong quy trình, do đó bạn có được một mật khẩu duy nhất cho mỗi trang web, ngay cả khi bạn luôn sử dụng lại cùng một mật khẩu.

Nó không phải là cực kỳ an toàn (base64-MD5), nhưng bạn phân phối hoàn hảo việc triển khai dựa trên sha-2 nếu bạn muốn.

Nhược điểm duy nhất là nếu tên miền thay đổi, trong trường hợp đó bạn sẽ cần yêu cầu trang web đặt lại mật khẩu của mình vì bạn sẽ không thể tự phục hồi nó ... mặc dù vậy, điều đó không xảy ra thường xuyên, vì vậy tôi coi đó là một đánh đổi chấp nhận được.

Tôi thích câu trả lời của X4u, nhưng theo ý kiến ​​của tôi, một cái gì đó giống như nó nên được tích hợp vào trình duyệt / đặc tả html - vì hiện tại nó chỉ là một nửa câu trả lời.

Đây là một vấn đề tôi gặp phải với tư cách là người dùng - Tôi không biết liệu mật khẩu của mình có bị băm ở đầu kia hay không khi được lưu trữ trong cơ sở dữ liệu. Các dòng giữa tôi và máy chủ có thể được mã hóa nhưng tôi không biết điều gì sẽ xảy ra với mật khẩu của mình khi nó đến đích - nó có thể được lưu trữ dưới dạng văn bản thuần túy. Anh chàng quản trị cơ sở dữ liệu có thể sẽ bán cơ sở dữ liệu và trước khi bạn biết nó, cả thế giới đều biết mật khẩu của bạn.

Hầu hết người dùng sử dụng lại mật khẩu. Những người không có kỹ thuật vì họ không biết gì hơn. Những người kỹ thuật bởi vì một khi bạn nhận được mật khẩu thứ 15 hoặc hầu hết mọi người sẽ không có cơ hội ghi nhớ chúng trừ khi họ viết chúng ra (Điều mà tất cả chúng ta đều biết cũng là một ý tưởng tồi).

Nếu Chrome hoặc IE hoặc bất cứ thứ gì tôi đang sử dụng có thể cho tôi biết rằng hộp mật khẩu sẽ ngay lập tức được phía khách hàng băm bằng cách sử dụng máy chủ tạo ra muối và sử dụng chính xác mật khẩu - tôi sẽ biết rằng với tư cách là người dùng tôi có thể sử dụng lại một mật khẩu với ít rủi ro hơn. Tôi vẫn muốn các kênh được mã hóa cũng như tôi không muốn bất kỳ mái hiên nào bị rơi trong quá trình truyền.

Người dùng cần biết rằng mật khẩu của họ thậm chí không có sẵn để được gửi đến máy chủ - chỉ có hàm băm. Hiện tại ngay cả khi sử dụng giải pháp của X4U, họ không có cách nào biết đây là trường hợp vì bạn không biết công nghệ đó có được sử dụng hay không.

Tôi nghĩ rằng đó là một phương pháp tốt để sử dụng khi xây dựng một cái gì đó như khung, CMS, phần mềm diễn đàn, v.v., nơi bạn không kiểm soát các máy chủ mà nó có thể được cài đặt. Đó là, CÓ, bạn nên luôn khuyến nghị sử dụng SSL để đăng nhập và hoạt động đăng nhập, nhưng một số trang web sử dụng khung / cm của bạn sẽ không có nó, vì vậy họ vẫn có thể hưởng lợi từ việc này.

Như những người khác đã chỉ ra, lợi ích ở đây KHÔNG phải là một cuộc tấn công MITM không thể cho phép người khác đăng nhập vào trang web cụ thể này như bạn, mà là kẻ tấn công đó sau đó sẽ không thể sử dụng cùng một tên người dùng / mật khẩu đăng nhập vào hàng chục trang web khác mà bạn có thể có tài khoản.

Một lược đồ như vậy nên muối với một loại muối ngẫu nhiên hoặc một số loại muối dành riêng cho trang web và tên người dùng cụ thể để những người lấy được mật khẩu không thể sử dụng nó cho cùng một tên người dùng trên các trang web khác (ngay cả các trang web sử dụng lược đồ băm giống hệt nhau ), cũng không chống lại những người dùng khác của trang web có thể có cùng mật khẩu.

Những người khác đã gợi ý rằng người dùng nên tạo mật khẩu duy nhất cho mỗi trang web họ sử dụng hoặc sử dụng trình quản lý mật khẩu. Trong khi đây là lời khuyên âm thanh trong lý thuyết, tất cả chúng ta đều biết điều này là hoàn toàn dựa vào thế giới thực. Tỷ lệ người dùng thực hiện một trong những điều này là nhỏ và tôi nghi ngờ điều đó sẽ sớm thay đổi.

Vì vậy, một mật khẩu javascript là loại ít nhất mà nhà phát triển khung / cm có thể làm để hạn chế thiệt hại của ai đó chặn mật khẩu trong quá trình (điều này dễ dàng qua mạng wifi hiện nay) nếu cả chủ sở hữu trang web và người dùng cuối đều sơ suất về bảo mật (mà họ có khả năng là).