Khi nào bạn nên lưu trữ mật khẩu bằng văn bản rõ ràng?

Question

Tôi đang làm việc trên một ứng dụng được nhắm mục tiêu ở những người dùng không có kỹ thuật. Tôi mong đợi một số lượng lớn các cuộc gọi hỗ trợ liên quan đến mật khẩu bị mất và không thể đăng nhập được.

Tôi đang sử dụng nhà cung cấp thành viên ASP.NET cung cấp 3 tùy chọn để lưu trữ mật khẩu - Xóa văn bản, Đã băm, Mã hóa.

Bạn nên lưu trữ mật khẩu ở dạng văn bản rõ ràng do tính chất của ứng dụng này? Có bất kỳ vấn đề pháp lý nào liên quan đến việc lưu trữ mật khẩu trong văn bản rõ ràng không?

Answer 1

Không bao giờ.

Có không bao giờ là lý do chính đáng để lưu trữ mật khẩu trong cơ sở dữ liệu của bạn, bao giờ hết. Đặc biệt là không phải bằng văn bản rõ ràng. Bạn phải lưu trữ mã băm của mật khẩu chỉ.

điều tồi tệ nhất điều bạn có thể thực hiện với người dùng là phát mật khẩu "đã khôi phục" trên Internet bằng e-mail rõ ràng. Nó là dễ dàng như vậy để chỉ lưu trữ một băm một chiều của mật khẩu mà không thể khôi phục được.

Đối với mật khẩu bị mất, bạn chỉ cần đặt lại mật khẩu của họ và cung cấp cho họ mật khẩu tạm thời mà họ phải thay đổi khi đăng nhập. An toàn và bảo mật.

Mọi người thường sử dụng cùng một mật khẩu cho nhiều ứng dụng (đặc biệt là người dùng không có kỹ thuật). Vì vậy, ứng dụng của bạn có thể sẽ chứa các mật khẩu cho các tài khoản ngân hàng của người dân, email, vv

Bạn có một trách nhiệm để đảm bảo mật khẩu của người sử dụng, không có vấn đề như thế nào không quan trọng ứng dụng của bạn.

Answer 2

Không, không bao giờ có ý tưởng hay, không có mather làm thế nào ngớ ngẩn ứng dụng của bạn.

Answer 3

Dưới đây là một vài lý do để sử dụng mật khẩu không được mã hóa:

1. Khi bạn không tôn trọng sự riêng tư của người dùng.
2. Khi bạn sắp bị sa thải khỏi công việc hiện tại của mình và muốn để lại ấn tượng lâu dài.
3. Khi bạn muốn người dùng chính của mình trở thành tin tặc Trung Quốc.

Nếu bạn cảm thấy như bất kỳ mục nào trong số đó phù hợp với mô hình kinh doanh của bạn, hãy tiếp tục và để mật khẩu của bạn không được mã hóa.

Answer 4

Đó là một ý tưởng hay nếu bạn có khả năng sử dụng trong tâm trí và ít nỗ lực hơn từ góc độ người dùng.

Tuy nhiên, bạn phải hiểu rằng, với tư cách là nhà phát triển, bạn cần đảm bảo người dùng của mình an toàn khi trực tuyến. Những gì người dùng muốn không phải lúc nào cũng tốt nhất cho họ.

Mọi người sử dụng cùng một mật khẩu trong nhiều tài khoản. Nếu db của bạn bị xâm nhập theo một cách nào đó, bạn đang cho đi các mật khẩu có thể được sử dụng trong các tài khoản ngân hàng chẳng hạn.

Nếu bạn cho rằng đặt lại mật khẩu không dành cho những người không phải là công nghệ cao, ít nhất hãy tạo biểu mẫu để thay đổi mật khẩu như Gmail.

Tôi không biết ở Hoa Kỳ, nhưng ít nhất ở quốc gia của tôi, nếu hệ thống bị xâm nhập lưu trữ mật khẩu của tôi, tôi sẽ cố gắng kiện họ vì chúng tôi có cách ngăn chặn lưu trữ mật khẩu văn bản rõ ràng.

Answer 5

Khi bạn muốn trang web của mình bị tấn công và bạn phải bảo đảm rằng dữ liệu người dùng của bạn bị đánh cắp hoặc bị hỏng.

Đó là khi bạn lưu trữ mật khẩu ở dạng văn bản rõ ràng.

Answer 6

Tôi cho rằng có một tình huống lưu trữ mật khẩu ở dạng văn bản rõ ràng là phù hợp.

Nếu bạn đang viết một ứng dụng để sử dụng làm ví dụ "trước" trong phần minh họa cách viết mã bảo mật để bạn có thể hiển thị cách triển khai các kỹ thuật mã hóa/băm mật khẩu.

Answer 7

Bạn không bao giờ nên lưu trữ mật khẩu trong cơ sở dữ liệu. Lưu trữ một băm mật khẩu (có thể muối). Trong trường hợp mất mật khẩu, hãy tạo một mật khẩu mới và gửi đến địa chỉ email đã được xác minh của họ - đảm bảo rằng họ thay đổi mật khẩu được tạo tự động này trong lần đăng nhập tiếp theo.

Đối tượng mục tiêu của bạn có thể không mang tính kỹ thuật, nhưng điều đó sẽ không xảy ra với bạn bè của họ là những người chơi khăm giản dị/chuyên nghiệp. Người dùng không phải kỹ thuật phải được chăm sóc cẩn thận vì họ có nhiều khả năng giữ cùng một tên người dùng/mật khẩu kết hợp cho ứng dụng nhỏ, tài khoản Google và tài khoản ngân hàng trực tuyến (nếu ngân hàng chấp nhận mật khẩu đó). Họ sẽ mất tài khoản/dữ liệu thư/tiền của họ và bạn sẽ mất lòng tin và khách hàng.

Đây là một bài viết trên blog về storing passwords in databases đáng đọc bởi @codinghorror

Answer 8

Bạn chỉ nên lưu trữ mật khẩu trong văn bản rõ ràng khi bạn muốn nó được thực sự dễ dàng cho bất cứ ai để có được chúng. Đối với usecase của bạn tôi sẽ đề nghị một tùy chọn mà người dùng nhập vào e-mailadress của họ và nhận được một e-mail có chứa một liên kết mà họ có thể đăng nhập. Khi đăng nhập họ sẽ có tùy chọn để thay đổi mật khẩu nếu họ muốn, nhưng nếu hầu hết người dùng không phải là khách truy cập thường xuyên, họ thậm chí có thể không muốn thay đổi mật khẩu của họ vì họ sẽ quên mật khẩu đó trước lần truy cập tiếp theo.

Answer 9

Nghiêm túc là tôi không nghĩ đó là một ý hay ...

Answer 10

Không bao giờ. "Bản chất của ứng dụng" không quan trọng. Bạn nên tự hỏi mình những gì bạn nghĩ rằng những lợi ích của việc lưu trữ nó trong văn bản rõ ràng là. Bạn có mong đợi hỗ trợ kỹ thuật để nhận điện thoại và cho họ biết mật khẩu của họ không? Hoặc gửi email cho họ khi họ quên nó? Đó không phải là ý tưởng hay.

Có một mẫu thiết kế xây dựng cho các mật khẩu:

1. Hash họ
2. Cung cấp cho người dùng với một liên kết Mật khẩu Quên
3. dùng nhập địa chỉ email liên kết với tài khoản của họ
4. Thiết lập lại liên kết hoặc tạm thời mật khẩu được tạo sẽ được gửi qua email tới địa chỉ của chúng
5. Chúng được nhắc ngay lập tức chỉ định mật khẩu mới khi truy cập liên kết hoặc sử dụng mật khẩu tạm thời.

Đó là tổng quan chung và đó là cách tiếp cận dự kiến. Các biến thể khác tồn tại, chẳng hạn như cung cấp câu hỏi bảo mật.

Answer 11

Để biết bất kỳ thông tin đáng tin cậy nào về lý do pháp lý, hãy tham khảo luật sư. Tại Hoa Kỳ, bạn sẽ có thể nhận được giới thiệu từ hiệp hội thanh địa phương của bạn. Tôi không phải là luật sư và đây không phải là lời khuyên pháp lý.

Điều đó nói rằng, nếu bạn đã từng vi phạm dữ liệu, bạn có thể phải chịu trách nhiệm về bất kỳ điều gì xảy ra trên trang web của mình, bao gồm khả năng chịu trách nhiệm về bất kỳ điều gì tài chính hoặc phỉ báng. Nếu người dùng sử dụng mật khẩu trên nhiều trang web, bạn có thể phải chịu trách nhiệm về hoạt động khác trên các trang web khác. Ở Mỹ, bạn có thể bị kiện vì khá nhiều thứ, và không rõ ràng với tôi rằng bạn sẽ thắng một bộ đồ như vậy.

Vì vậy, các khoản nợ pháp lý có khả năng lớn. Tham khảo luật sư trước khi lưu mật khẩu rõ ràng.

Answer 12

Tính bảo mật và khả năng sử dụng ở các đầu đối diện của cùng một thanh. Khi bạn làm cho ứng dụng của bạn dễ sử dụng, chẳng hạn như cung cấp cho người dùng mật khẩu của họ lại, bạn sẽ làm cho nó không an toàn. Khi bạn làm cho ứng dụng của bạn hỏi 5 câu hỏi, một mẫu máu, và một mật khẩu thậm chí Einstein sẽ quên, bạn có vấn đề về khả năng sử dụng.