Làm cách nào để đảm bảo người dùng rằng trang web và mật khẩu được bảo mật [đóng]

Trên các trang web đáng tin cậy, tôi luôn thấy các khiếu nại như "Tất cả dữ liệu được mã hóa" hoặc "Tất cả mật khẩu được mã hóa bằng mã hóa 128 bit", v.v. Tuy nhiên, tôi chưa bao giờ gặp phải khiếu nại nào như "Tất cả mật khẩu được băm".

Trên trang web của tôi, tôi sẽ lưu trữ tất cả mật khẩu người dùng trong cơ sở dữ liệu sau khi sử dụng băm SHA-512 (rất có thể) với một muối ngẫu nhiên. Tôi muốn thêm một snipet đảm bảo người dùng rằng mật khẩu của họ được bảo mật để họ không bị ngăn cản sử dụng trang web của tôi vì nó yêu cầu mật khẩu. Tôi muốn người dùng cảm thấy an toàn nhưng tôi không nghĩ mọi người đều biết băm là gì.

CÂU HỎI CỦA TÔI: Có ổn không khi cung cấp một thông báo nói rằng "Tất cả mật khẩu được mã hóa và bảo mật" vì tôi không nghĩ rằng người dùng trung bình sẽ biết sự khác biệt giữa băm và mã hóa là gì, và nhiều khả năng sẽ cảm thấy an toàn chỉ vì họ thấy từ "mã hóa" thoải mái? Hoặc có một thông điệp thay thế tôi nên cung cấp?

Bên cạnh đó, tôi chưa quen với mã hóa và băm mật khẩu và tôi đã tự hỏi liệu điều này có đủ an toàn cho đến bây giờ khi tôi khởi chạy trang web của mình không. Tôi không muốn nói với người dùng rằng nó an toàn nếu không. Bất kỳ thông tin sẽ được đánh giá rất cao. Cảm ơn.

1. Người dùng không quan tâm.

   Lần duy nhất họ quan tâm là khi ai đó rút tiền từ tài khoản ngân hàng của họ và có vẻ như nó có một liên kết mà vài ngày trước, ai đó đã có được quyền truy cập đầy đủ vào cơ sở dữ liệu của bạn.

2. Trong hầu hết mọi trường hợp tôi thấy những tin nhắn như vậy, chúng đều gây hiểu nhầm. Điều thú vị nhất là trên một trang web có nhãn kiểu "an toàn cấp độ quân đội" trên mỗi trang. Có một cảnh báo cho biết rằng chứng chỉ HTTP không hợp lệ. Có một SQL tiêm trên hình thức đăng nhập. Vài tuần sau, trang web bị hack, rồi biến mất vĩnh viễn.

   Tôi ngừng đếm số lượng trang web tuyên bố rằng họ giữ thông tin an toàn, trong khi có biểu mẫu "Khôi phục mật khẩu của tôi", thực sự sẽ gửi mật khẩu gốc qua e-mail.

   Nó giống như các nhãn "WHTML X hợp lệ". Tại sao chúng thường được đặt trên các trang web trong đó ngay cả một trang chủ chứa ít nhất hàng tá lỗi và mã như thế <DIV COLOR='red'>nào?

Nếu bạn vẫn muốn trấn an người dùng, bạn có thể đặt một cái gì đó như:

Mật khẩu của bạn được giữ an toàn. Hãy nhớ rằng chúng tôi không thể thấy mật khẩu của bạn và sẽ không bao giờ gửi email cho bạn yêu cầu bạn cung cấp mật khẩu.

Nhưng thành thật mà nói, mẫu "Đặt lại mật khẩu của tôi" thay thế cho "Tôi quên mật khẩu của mình; gửi nó cho tôi bằng e-mail" yên tâm hơn nhiều so với bất kỳ từ nào.

Gợi ý từ các ý kiến ​​khác nhau:

• Đừng phát minh lại bánh xe: sử dụng OpenID. Bằng cách này, bạn thậm chí không lưu trữ băm.

  Nguồn: bình luận của Jan Hudec .

• Vì bạn là sinh viên, hãy mở nguồn dự án của bạn. Vì mối quan tâm của bạn là: "Tôi không muốn người dùng nghĩ rằng mật khẩu của họ không an toàn vì một số đứa trẻ ở trường đã thiết kế nó." , không có gì yên tâm hơn khi có thể kiểm tra, bằng cách đọc mã nguồn, rằng nó được viết bởi một nhà phát triển khéo léo, người quan tâm đến bảo mật.

  Nguồn: bình luận của Jan Doggen .

Đừng lưu trữ mật khẩu ở nơi đầu tiên! Thực hiện theo ví dụ về Stack Exchange và cho phép người dùng đăng nhập bằng danh tính của họ trên một trang web khác cung cấp xác thực qua OpenID . Việc triển khai có sẵn miễn phí cho hầu hết các khung web phổ biến.

Hoặc có thể bất kỳ giao thức khác. Nếu đó là dự án nội bộ cho một số tổ chức (như nhận xét của bạn về câu trả lời khác cho thấy), thì gần như chắc chắn đã có LDAP, Kerberos (Windows Active Directory cũng dựa trên cả hai; apache hỗ trợ xác thực HTTP chống lại chúng) hoặc một số dịch vụ như vậy để đăng nhập máy tính. Chỉ cần kết nối với điều đó.

Điều này giúp bạn không lưu trữ thông tin nhạy cảm (rất có thể bạn vẫn phải lưu trữ quyền, nhưng chúng không quá quan trọng) và người dùng không phải nhớ tên người dùng và mật khẩu khác, vì vậy, win-win nói chung.

Nói:

"Điều này là an toàn."

là một bản án cá nhân bạn đưa ra về các sự kiện hoặc quy trình công nghệ nhất định và phán quyết này bị giới hạn bởi những gì bạn biết về bảo mật tại thời điểm đó. Nhưng bạn có thể đảm bảo chắc chắn rằng mã hóa, phương thức lưu trữ, v.v. của bạn sẽ chống lại bất kỳ loại tấn công nào, ngay cả những loại bạn chưa biết hoặc chưa biết về?

Ý nghĩa: Tuyên bố này có nguy cơ bị lỗi thời, thậm chí có thể không có bạn nhận thức được nó.

Vì vậy, tôi có xu hướng đồng ý với những nhận xét trên bằng cách @JoachimSauer: Chỉ cần mô tả những gì bạn làm, làm thế nào giúp bạn tiết kiệm thông tin người dùng, và cho người dùng cách này được cho là để làm cho dịch vụ của bạn an toàn. Sau đó để người dùng tự đánh giá.

Nó thực sự phụ thuộc vào bối cảnh của trang web cụ thể của bạn.

Ví dụ: nếu đây là một trang web của người tiêu dùng, tỷ lệ cược là hầu hết họ sẽ chỉ quan tâm đến mật khẩu của họ (có thể), thông tin tài chính / sức khỏe (tùy thuộc) và thông tin cá nhân của họ như hình ảnh (hahaha, yeah phải ...) .

Nếu đây là một ứng dụng kinh doanh, thì mức độ bảo mật của toàn bộ trang web có liên quan, không chỉ là mật khẩu. Tương tự, nó phụ thuộc vào người dùng mục tiêu của bạn là ai - kỹ thuật cao / không quá kỹ thuật, v.v.

Tất cả bối cảnh này xác định rất rõ những gì bạn nên giao tiếp, và mức độ đảm bảo là bắt buộc.

Ví dụ, đối với người tiêu dùng phi kỹ thuật, việc có một số nhận xét chung chung, đơn giản là:

Trang web này được xây dựng bằng các kỹ thuật bảo mật tiên tiến nhất. Mật khẩu của bạn luôn được mã hóa và chúng tôi sẽ không bao giờ gửi ảnh của bạn đến NSA.

(Và, như những người khác đã nói, tốt hơn hết là bạn thậm chí không có mật khẩu, hãy sử dụng một số tiêu chuẩn như OpenId hoặc OAuth.)

Đối với các doanh nghiệp kỹ thuật cao, bạn sẽ muốn có một trang đầy đủ các chi tiết về kỹ thuật và thủ tục, chẳng hạn như:

Chúng tôi đã triển khai SDL đầy đủ (vòng đời phát triển an toàn) trong suốt quá trình phát triển và triển khai của mình.
...
Kiến trúc bảo mật của chúng tôi là ... Điều này mang lại lợi ích của ...
Chúng tôi đảm bảo mã hóa an toàn như ... bởi ... Chúng tôi thực hiện những thử nghiệm này và những thử nghiệm đó.
Mật mã học của chúng tôi bao gồm các thuật toán này ... và ... Chúng tôi tuân thủ bất kỳ quy định nào của ngành mà bạn cần và được chứng nhận cho ...
Bảo mật của chúng tôi được xác minh bởi nhà tư vấn bên thứ 3 độc lập này.
...
Để biết thêm chi tiết và xem xét các chính sách của chúng tôi hoặc sắp xếp kiểm toán độc lập, vui lòng thảo luận với bộ phận tiếp thị.

Tất nhiên, bạn không muốn cung cấp quá nhiều thông tin chi tiết, nó nên liên quan đến quá trình hơn là mật khẩu ... Và tất nhiên, không nên nói rằng thực tế nên thực sự tuân thủ bất cứ điều gì bạn viết ở đó , bất cứ bối cảnh nào bạn đang đối phó.

Là một trong những câu trả lời được nhắc đến, hầu hết người dùng không quan tâm, sẽ không hiểu bất cứ điều gì bạn nói với họ và dù sao họ vẫn sẽ đăng ký, ngay cả khi bạn nói rằng bạn KHÔNG gửi dữ liệu người dùng đến NSA.
Điều này không dành cho họ.
Họ sẽ rất vui khi không có bất kỳ mật khẩu nào, chỉ cần để tôi chọn tên người dùng từ danh sách và tự động đăng nhập.

Rõ ràng đây là phần trăm nhỏ mà bạn quan tâm - bạn nên cho phép người dùng thông minh thực hiện đúng, cung cấp cho họ thông tin họ cần và cấp cho họ nền giáo dục họ có thể yêu cầu.
Nếu bạn không, khi điều đó xảy ra, 98% còn lại sẽ đột nhiên tỉnh dậy và tức giận.
("Chắc chắn, tôi biết rằng tôi không cần mật khẩu để xem ảnh của mình, nhưng tôi không nghĩ rằng ai khác cũng có thể nhìn thấy chúng !!")

Nếu bạn muốn hệ thống của mình được bảo mật, sức mạnh của thuật toán mật khẩu là vô nghĩa - hầu hết các tin tặc có thể bẻ khóa mật khẩu ngay lập tức, đặc biệt là nếu mật khẩu được chọn nhỏ hoặc bao gồm các từ chung chung mà tin tặc đã "bẻ khóa và lưu trữ "Bảng cầu vồng usiong và tương tự. Đọc bài viết của ArsTechnica về bẻ khóa mật khẩu để có cái nhìn sâu sắc.

Những gì bạn cần làm là đảm bảo với người dùng rằng kẻ xấu không thể có được băm của họ ngay từ đầu. Một công ty có ý thức bảo mật mà tôi làm việc có một hệ thống web 3 tầng trong đó các máy chủ web không được kết nối với các máy chủ cơ sở dữ liệu. Khi ông chủ của tôi muốn đưa trang web của anh ấy vào và có quyền truy cập trực tiếp vào DB (mã được thiết kế kém, 'nuff nói) anh ấy đã nói rằng anh ấy không thể có nó, và khi anh ấy đẩy ... đã nói rằng không có dây giữa họ . Anh ta phải kiến ​​trúc sư để nó chuyển tất cả các yêu cầu dữ liệu thông qua một dịch vụ trung gian. Và những dịch vụ đó không chỉ được bảo mật mà còn lộ ra bề mặt tối thiểu để tấn công và bị khóa. Và DB không bao giờ để lộ bất kỳ bảng nào của nó để đọc, chỉ các thủ tục được lưu trữ lần lượt bị khóa để chỉ dịch vụ có liên quan mới có quyền truy cập.

Viết mã không tệ như bạn nghĩ, một khi bạn đã biết kiến ​​trúc và sự tách biệt của từng tầng, việc mã hóa khá dễ dàng.

Bạn có thể phát triển trang web an toàn nhất trên hành tinh và có trải nghiệm người dùng thực sự kém. Người dùng sẽ cho rằng trang web của bạn không an toàn.

Bạn có thể xây dựng trang web kém an toàn nhất trên hành tinh và có trải nghiệm người dùng tuyệt vời. Người dùng sẽ cho rằng trang web của bạn an toàn. Ít nhất cho đến khi nó xuất hiện trên tin tức buổi tối.