Trích dẫn cho tính không hợp lệ của mật khẩu duy nhất trên toàn cầu

Tôi đang có bất đồng với ai đó (khách hàng) về quy trình xác thực / xác thực người dùng cho một hệ thống. Điểm chung của nó là họ muốn mỗi người dùng có một mật khẩu duy nhất trên toàn cầu (nghĩa là không có hai người dùng nào có thể có cùng một mật khẩu). Tôi đã đưa ra tất cả các lập luận rõ ràng chống lại điều này (đó là một lỗ hổng bảo mật, nó nhầm lẫn giữa nhận dạng với xác thực, nó là vô nghĩa, v.v.) nhưng họ khẳng định rằng không có gì sai với phương pháp này.

Tôi đã thực hiện nhiều tìm kiếm khác nhau trên google để tìm kiếm ý kiến ​​có thẩm quyền (hoặc bán độc quyền hoặc thậm chí chỉ độc lập) về vấn đề này, nhưng không thể tìm thấy bất kỳ (chủ yếu chỉ là một trò giả mạo rõ ràng mà nó dường như không đáng để cảnh báo, như xa như tôi có thể nói). Bất cứ ai có thể chỉ cho tôi về bất kỳ ý kiến ​​độc lập như vậy, xin vui lòng?

[EDIT]
Cảm ơn tất cả các câu trả lời của bạn, nhưng tôi đã hiểu các vấn đề với cách tiếp cận / yêu cầu được đề xuất này và thậm chí có thể giải thích chúng cho khách hàng, nhưng khách hàng không chấp nhận chúng, do đó tôi yêu cầu các nguồn độc lập và / hoặc có thẩm quyền .

Tôi cũng đã tìm thấy bài báo WTF hàng ngày, nhưng nó gặp phải vấn đề mà Jon Hopkins đã chỉ ra - rằng đây là một WTF rõ ràng đến mức nó dường như không đáng để giải thích tại sao .

Và vâng, mật khẩu sẽ được muối và băm. Trong trường hợp tính duy nhất toàn cầu có thể khó đảm bảo, nhưng điều đó không giải quyết được vấn đề của tôi - điều đó chỉ có nghĩa là tôi có một yêu cầu là khách hàng sẽ không nhúc nhích, điều đó không chỉ gây khó chịu mà còn khó khăn triển khai thực hiện. Và nếu tôi ở vào vị trí để nói "Tôi không nhúc nhích muối và băm", thì tôi sẽ ở vị trí để nói "Tôi không thực hiện mật khẩu duy nhất trên toàn cầu".

Bất kỳ con trỏ nào đến các nguồn độc lập và / hoặc có thẩm quyền về lý do tại sao đây là một ý tưởng tồi vẫn nhận được một cách biết ơn ...
[/ EDIT]

Bất cứ khi nào khách hàng cố gắng tạo mật khẩu đã tồn tại, họ sẽ nhận được phản hồi rằng một số người dùng đã sử dụng mật khẩu đó, thường là vi phạm thỏa thuận bảo mật.

Bên cạnh đó, tên người dùng dễ đoán hơn nhiều (và nếu có một diễn đàn, bạn có thể tìm thấy rất nhiều tên người dùng ở đó) và bạn đang gợi ý cho người dùng cách hack trang web.

Cần có một số trang trên internet ở đâu đó mô tả phần vi phạm thỏa thuận quyền riêng tư, ngoài điều đó chỉ là lẽ thường: về cơ bản họ sẽ đưa cho ai đó một chìa khóa và một danh sách các địa chỉ nhà.

EDIT: Không gần với tác giả, nhưng có lẽ hữu ích sau khi bạn giải thích cho họ ý nghĩa của WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

Thực hành tốt nhất có được trong cách đáp ứng yêu cầu:

Bạn không thể làm điều này bởi vì bạn không biết mật khẩu là gì nên bạn không thể so sánh chúng vì tất cả những gì bạn lưu trữ là hàm băm của mật khẩu và muối (mà bạn có thể lưu trữ bên cạnh mật khẩu được băm). Đây là cách thực hành tốt nhất, vì vậy đó là những gì bạn làm. Làm xong.

Một chỉnh sửa khác: Doh! Hindsight rất dễ dàng - bạn vẫn có thể kiểm tra tính độc đáo bởi vì (tất nhiên) bạn có muối ... chỉ cần bắn tôi bây giờ ... tất nhiên bạn không phải đề cập đến chi tiết này cho khách hàng.

FWIW, nó không hoàn toàn ngu ngốc như bạn nghĩ - mục đích là để ngăn chặn các nhóm người dùng đồng ý và chia sẻ cùng một mật khẩu, mọi người sẽ làm với niềm tin rằng nó sẽ giúp cuộc sống của họ dễ dàng hơn.

Nếu được áp dụng với yêu cầu thay đổi mật khẩu thường xuyên và một ràng buộc ngăn mọi người sử dụng lại mật khẩu hiện tại hoặc đã sử dụng trước đó (tất cả, bao giờ) và các yêu cầu "sức mạnh" hợp lý (hoặc ít nhất là một từ điển được tải sẵn "bị chặn" "Mật khẩu) bạn sẽ đi đến một điểm, khá nhanh chóng, trong đó tỷ lệ cược không phải là lợi ích của hacker.

Ok, câu trả lời của tôi ban đầu bắt đầu bằng:

Có rất ít sai lầm với điều này được đưa ra một vài điều khoản - hầu hết trong số đó là tôi đang ...

Sự hài hước không phù hợp rõ ràng - điểm là nếu bạn không có sự ràng buộc độc nhất toàn cầu, bạn sẽ tạo ra những cơ hội khác nhau, có lẽ ít nguy hiểm hơn - tôi không biết.

Thực thi mật khẩu không thể lặp lại rò rỉ thông tin

Làm sao? Bởi vì mỗi khi cracker cố gắng tạo một người dùng mới bằng một mật khẩu đơn giản, hệ thống của bạn sẽ phản hồi bằng "Không, không thể có mật khẩu đó", cracker nói "Goody, đó là một trong danh sách".

Rò rỉ thông tin về bảo mật của bạn nói chung là một điều xấu. OK, các bên thứ ba biết thuật toán là tốt (nó cần đánh giá ngang hàng) nhưng cho phép một trình bẻ khóa chuyên dụng để suy ra các khóa - xấu, thực sự, thực sự xấu.

Tài nguyên mô tả chính sách quản lý mật khẩu tốt và xấu

Đọc bài viết này của chuyên gia bảo mật Bruce Schneier để thảo luận chuyên sâu về độ mạnh của mật khẩu.

Đọc bản PDF này của các nhà nghiên cứu bảo mật Philip Inglesant & M. Angela Sasse để thảo luận chuyên sâu về "Chi phí thực sự của các chính sách mật khẩu không thể sử dụng". Để trích dẫn từ kết luận:

Chống lại thế giới rằng, nếu chỉ [người dùng] hiểu được các mối nguy hiểm, họ sẽ hành xử khác nhau [12], chúng tôi lập luận rằng nếu chỉ các nhà quản lý bảo mật hiểu được chi phí thực sự cho người dùng và tổ chức, họ sẽ đặt ra các chính sách khác nhau.

Sai cảm giác an toàn

Vì vậy, khách hàng bỏ qua, "Nếu không ai có cùng mật khẩu thì nếu ai đó bị bẻ khóa thì chỉ có một người bị ảnh hưởng." Không. Mọi người đều bị ảnh hưởng vì trình bẻ khóa đã chứng minh rằng hệ thống mật khẩu của bạn bị thiếu sót một cách cơ bản: nó dễ bị tấn công từ điển trong một hệ thống trực tuyến. Không nên để một kẻ bẻ khóa thử nhiều lần đoán mật khẩu ở nơi đầu tiên.

Đối với truy cập trực tuyến 6 ký tự là đủ

Đi lạc đề, nhưng tôi nghĩ nó sẽ đáng được đề cập cho những độc giả quan tâm. Về mặt bảo mật, một hệ thống trực tuyến là một hệ thống có quy trình quản lý bảo mật tích cực giám sát và kiểm soát truy cập dữ liệu. Một hệ thống ngoại tuyến là một hệ thống không có (chẳng hạn như có dữ liệu được mã hóa trên đĩa cứng đã bị đánh cắp).

Nếu bạn có một hệ thống mật khẩu trực tuyến thì bạn không cần mật khẩu bảo mật cao. Mật khẩu chỉ phải đủ phức tạp để tránh đoán trong vòng 20 lần thử (vì vậy một cuộc tấn công "tên của vợ / chồng / con / thú cưng" đơn giản sẽ thất bại). Hãy xem xét các thuật toán sau:

1. Cracker đoán mật khẩu bằng cách sử dụng phương pháp "root plus hậu tố" để giảm thiểu số lần đoán
2. Thông tin đăng nhập bị từ chối và các lần đăng nhập tiếp theo bị chặn trong N * 10 giây
3. Nếu N> 20 khóa tài khoản và thông báo cho quản trị viên
4. N = N +1
5. Thông báo cho người dùng rằng lần đăng nhập tiếp theo có thể xảy ra tại thời điểm T (đã tính ở trên)
6. Bước 1

Đối với mật khẩu 6 ký tự đơn giản, thuật toán trên sẽ ngăn chặn các cuộc tấn công từ điển, đồng thời cho phép ngay cả người dùng kém nhất trên bàn phím di động cuối cùng cũng có thể vượt qua. Không có gì có thể ngăn chặn cái gọi là "cuộc tấn công ống cao su" nơi bạn đánh bại người giữ mật khẩu bằng ống cao su cho đến khi họ nói với bạn.

Đối với một hệ thống ngoại tuyến khi dữ liệu được mã hóa nằm xung quanh ổ đĩa flash và trình bẻ khóa được tự do để thử bất cứ điều gì chống lại nó, bạn muốn có khóa linh hoạt nhất mà bạn có thể tìm thấy. Nhưng vấn đề đó đã được giải quyết .

Nếu bạn đã khuyên họ chống lại quá trình hành động này và cung cấp cho họ lý do, tôi sẽ nói với họ và chỉ thực hiện hệ thống như họ đề xuất. Nó có thể không thỏa mãn, nhưng bạn đã hoàn thành công việc của mình và họ đang thanh toán hóa đơn, vì vậy họ phải có được những gì họ muốn.

Có một ngoại lệ. Nếu hậu quả tiêu cực của vi phạm hệ thống sẽ nghiêm trọng (ví dụ: nếu thông tin rất riêng tư có khả năng bị xâm phạm do vi phạm an ninh) thì thực tế bạn có thể có nghĩa vụ chuyên nghiệp không thực hiện hệ thống mà họ muốn. Đừng hy vọng nó sẽ khiến bạn nổi tiếng nếu bạn từ chối, nhưng đừng để đó là hướng dẫn của bạn.

Tôi chỉ muốn củng cố câu trả lời của Murph. Vâng, đó là một vấn đề bảo mật và có lỗ hổng tiết lộ thông tin trong việc thực hiện nó. Nhưng theo quan điểm của khách hàng, anh ta dường như không quá lo lắng về điều đó.

Những gì bạn nên chỉ ra là thực tế không thể thực hiện kiểm tra "mật khẩu duy nhất". Nếu bạn đang muối và băm mật khẩu và không lưu trữ chúng dưới dạng văn bản rõ ràng, thì đó là thao tác O (n) (đắt tiền) để thực sự kiểm tra tính duy nhất.

Bạn có thể tưởng tượng nếu bạn có 10.000 người dùng và phải mất 30 giây để đi qua mọi mật khẩu của người dùng để kiểm tra tính duy nhất mỗi khi ai đó mới đăng ký hoặc thay đổi mật khẩu của họ không?

Tôi nghĩ rằng đây là phản hồi bạn cần đưa ra cho khách hàng của bạn.

Chỉ cần suy nghĩ về vị trí thích hợp để đặt câu hỏi, phần bảo mật CNTT của Stack Exchange sẽ là một điểm hữu ích cho bạn. Hãy thử /security/tagged/passwords - một loạt các cá nhân tập trung vào Bảo mật CNTT sẽ có thể cung cấp câu trả lời cụ thể.

Anh ta có thể muốn mã hóa hai yếu tố RSA. Nếu bạn đang sử dụng Active Directory hoặc thành viên ASP.NET thì đây là một việc không có trí tuệ.

Mã thông báo phần cứng hoặc phần mềm tạo mật khẩu duy nhất phụ thuộc vào thời gian được theo sau bởi mã PIN. Điều này cùng cung cấp một mật khẩu duy nhất cho mỗi người dùng.