Trừng phạt người dùng vì mật khẩu không an toàn [đã đóng]

Tôi đang suy nghĩ về việc giới hạn quyền của người dùng chọn mật khẩu không an toàn (độ không an toàn của mật khẩu được xác định theo độ dài, có bao nhiêu loại ký tự (chữ hoa / chữ thường, số, ký hiệu, v.v.) được sử dụng và liệu nó có thể nằm trong bảng cầu vồng) để hạn chế mức độ thiệt hại mà tài khoản của họ có thể gây ra nếu bị xâm phạm.

Tôi chưa có ứng dụng cho ý tưởng này, nhưng nói rằng tôi đang viết một diễn đàn hoặc một cái gì đó: Người dùng sử dụng mật khẩu 1234 có thể phải điền captcha trước khi đăng hoặc phải chịu các biện pháp chống thư rác nghiêm ngặt như vậy như thời gian chờ hoặc bộ lọc Bayes từ chối nội dung của chúng. Nếu diễn đàn này rất phân cấp, cho phép "quảng bá" cho người điều hành hoặc bằng bất kỳ cách nào, điều này sẽ ngăn họ giành được đặc quyền hoặc nói với họ rằng họ có đặc quyền, nhưng không cho phép họ thực hiện chúng mà không thay đổi để an toàn hơn mật khẩu.

Tất nhiên đây không thể là biện pháp bảo mật duy nhất, nhưng nó có thể hoạt động tốt bên cạnh các biện pháp bảo mật tốt.

Bạn nghĩ sao? Đây có phải là việc làm quá sức, đánh cắp sự tập trung khỏi các thực tiễn bảo mật quan trọng hơn hay là một cách tốt để hạn chế rủi ro và khuyến khích người dùng sử dụng mật khẩu an toàn hơn (và hy vọng thuyết phục những người bạn đang sử dụng các thực tiễn bảo mật tốt)?

YAGNI , KISS , DRY , quy tắc 10 giây và thực tế là "[u] không quan tâm đến BẠN" có lẽ nên thu hẹp nó thành một giải pháp: Đừng.

• Đó là công việc phát triển hơn cần nhiều thử nghiệm để đáng tin cậy và an toàn.
• Nó có thể làm giảm tính bảo mật của trang web bất kỳ cách nào bạn nhìn vào nó. Cơ hội của một số lỗi dẫn đến leo thang đặc quyền với một mật khẩu khủng là quá lớn.
• Nó làm tăng sự phức tạp cho nhà phát triển, người thử nghiệm, người bảo trì, DBA, sysadmin và người dùng.
• Càng phức tạp, càng khó tránh khỏi việc lặp lại chính mình theo một cách nào đó.
• Người dùng không có khoảng chú ý để đọc thông tin của bạn và theo dõi thông tin đó. Chúng được sử dụng để điều chỉnh biểu mẫu đăng ký cho đến khi nó chấp nhận đầu vào, cho đến khi chúng đạt đến một mức lý tưởng.
• Người dùng không quan tâm.

Hoặc buộc mật khẩu an toàn khi thay đổi đăng ký hoặc sử dụng OpenId (2c của Jeff Atwood: http : //www.codinghorror.com/blog/2010/11/your-iNET-drivers-license.html ). Sau đó tập trung vào chức năng thú vị hơn.

Đối với một điều, người dùng đã quen với việc buộc phải tạo mật khẩu an toàn hoặc sử dụng OpenId của họ, vì vậy thật đơn giản đối với họ.

Tại sao cho phép mật khẩu bạn cảm thấy xấu ngay từ đầu? Dừng vấn đề tại nguồn sẽ giúp bạn tiết kiệm rất nhiều thời gian thiết kế khi cố gắng tìm ra các lớp mật khẩu ánh xạ tới vai trò nào. Vì một quản trị viên, theo định nghĩa, sẽ có toàn quyền, bạn sẽ cần chức năng để đảm bảo anh ta không nhập mật khẩu sẽ hạn chế anh ta.

Câu trả lời của tôi thực sự đi xuống KISS .

Là người dùng, điều đó có thể sẽ thuyết phục tôi không sử dụng trang web của bạn. Ý tôi là, nghiêm túc, ngân hàng của tôi nói với tôi mã 6 chữ số hoàn toàn an toàn cho ngân hàng trực tuyến, nhưng khi tôi muốn viết bình luận cho một số blog ít được biết đến, tôi phải nhớ một mật khẩu duy nhất chứa ít nhất 8 mật khẩu - và các ký tự chữ thường, một chữ số, một ký tự đặc biệt và ký hiệu Hy Lạp hoặc Cyrillic chỉ có thể được nhập nếu bạn biết chuỗi unicode theo trái tim. Và thay đổi nó thường xuyên.

Đừng hiểu lầm tôi, an ninh là quan trọng. Nhưng nếu bạn không nên làm phiền người dùng của mình trừ khi bạn có lý do thực sự mạnh mẽ để tin rằng ai đó sẽ cố gắng bẻ khóa mật khẩu của họ để có quyền truy cập vào trang web của bạn. Nếu trang web của bạn tình cờ cung cấp quyền truy cập VPN vào mạng FBI, hãy tiếp tục, gây phiền nhiễu. Nhưng nếu đó là một diễn đàn người dùng nơi bất kỳ ai có địa chỉ email đều có thể đăng ký, thì thực sự vấn đề là gì?

Giải pháp tốt hơn: mặt cười.

Tôi nghiêm túc đấy! Đọc những cuốn sách kinh tế học hành vi như "Nudge: Cải thiện các quyết định về sức khỏe, sự giàu có và hạnh phúc" đã thuyết phục tôi về một vài điều:

1. Bạn không thể bắt mọi người phải đưa ra quyết định sáng suốt.
2. Mọi người thích được tự do lựa chọn, nhưng họ không thích nhiều lựa chọn.
3. Tuy nhiên, bạn có thể ảnh hưởng đáng kể đến sự lựa chọn của họ để tốt hơn với các thủ thuật đơn giản.

Tôi thấy những nguyên tắc này áp dụng cho tình huống của bạn như thế này:

1. Việc hạn chế người dùng dựa trên mật khẩu không an toàn rất có thể sẽ làm nản lòng và nhầm lẫn họ ... đặc biệt là đối với phần lớn những người không đọc các giải thích được viết cẩn thận trong các hộp thoại và chỉ cần gọi cho Helpdesk để nói, "Không công việc."
2. Khi tạo mật khẩu, người dùng không cần phải xem danh sách tất cả các khả năng của các ký tự đặc biệt và họ có thể sử dụng. Tốt hơn là chỉ cho họ một cửa sổ bật lên nhỏ gợi ý rằng họ chỉ thêm một số phức tạp nếu mục nhập của họ không đáp ứng yêu cầu.
3. Mọi người bị ảnh hưởng mạnh mẽ bởi các tín hiệu xã hội - ngay cả những người nhỏ bé như khuôn mặt hạnh phúc cho thấy chúng ta tán thành hành vi của họ, hoặc khuôn mặt nhăn nhó nếu chúng ta không. Một số trang web được thiết kế tốt hơn sẽ hiển thị thanh tiến trình được tô màu thay đổi từ màu đỏ thành Không đủ tốt :( sang màu xanh cho Công việc tốt! :) khi người dùng nhập mật khẩu và xác nhận (đề xuất) của họ. Giao diện người dùng này cung cấp cho họ một số áp lực xã hội để đáp ứng các tiêu chuẩn - để làm cho thanh chuyển sang màu xanh lục hoặc thay đổi nụ cười thành một nụ cười - khi họ tự khám phá ra cách tạo mật khẩu an toàn hơn với sự trợ giúp của phản hồi tức thì của thay đổi màu sắc.

Không chồng chất, nhưng tôi nghĩ ra một lý do khác để nộp cái này trong mục "Ý tưởng tồi" mà tôi chưa thấy đề cập đến - hỗ trợ khách hàng.

Nếu đây là một sản phẩm sẽ có hỗ trợ khách hàng đại diện đằng sau nó, họ sẽ không thích điều này lắm. Một trong những giả định cơ bản của hỗ trợ là họ hiểu và có thể dự đoán trải nghiệm người dùng - nếu họ đang hỗ trợ người dùng thông thường, thì Trang 1 nên có liên kết đến Trang 2, 3 và 4, nơi họ có thể thực hiện X, Y, Z , Vân vân.

Bây giờ, bạn đang cung cấp cho họ một biến khác mà họ phải theo dõi. Nếu người dùng không thấy liên kết đến Trang 4, có phải vì họ đã làm điều gì đó ngu ngốc? Hoặc là do mật khẩu của họ bị hút và hệ thống của bạn đang trừng phạt họ bằng cách từ chối họ truy cập vào Trang 4? Đợi đã ... tào lao, là từ chối truy cập vào một trong những hình phạt cho một mật khẩu xấu, hay tôi đang nghĩ về Trang 5? Hãy để tôi xem xét, chỉ một lát thôi ... được thôi, nó nói rằng đối với một mật khẩu không trộn lẫn chữ in hoa và in thường, việc truy cập vào các trang có số chẵn được cho phép nhưng bị hạn chế chỉ đọc ... được, Thưa ông, mật khẩu của bạn, nó có bao gồm tất cả chữ hoa hay chữ thường không? Trường hợp. Khi bạn chỉ cần gõ chữ cái, đó là chữ thường; Khi bạn sử dụng ca, đó là khi nó viết hoa. Bạn đã trộn các trường hợp trong mật khẩu của bạn? Mật khẩu bạn đã sử dụng để đăng nhập vào hệ thống. Một trong những bạn vừa sử dụng. Được rồi, đi đến Chỉnh sửa, sau đó chọn Tùy chọn, rồi Bảo mật. Chọn "Mật khẩu đã lưu" ... không, thưa ông, tôi không thể thấy mật khẩu của bạn từ đây ....

Vâng. Đừng làm điều này.

Hoặc hạn chế mật khẩu hoặc thông báo cho người dùng về những rủi ro của mật khẩu yếu. Tôi đoán nếu người dùng không quan tâm đến dữ liệu của họ, bạn có thể muốn hạn chế quyền truy cập vào dữ liệu của người khác. Có lẽ người dùng cảm thấy tự tin hơn nếu những người tuân theo các thực hành mật khẩu bất cẩn bị loại bỏ. Điểm yêu cầu mật khẩu mạnh hơn là gì nếu nó sẽ kết thúc bằng một ghi chú dán dưới bàn phím hoặc gõ vào máy tính xách tay (Không thể tạo ra thứ đó; Tôi đã thấy điều đó xảy ra.).

và liệu nó có thể được đặt trong một bàn cầu vồng

Tôi đoán bạn có nghĩa là từ điển và không phải bảng cầu vồng. Tấn công từ điển hoạt động trên chỉ kiểm tra tất cả các từ của từ điển nếu chúng khớp với mật khẩu. Cuộc tấn công này có thể được khắc phục bằng 5 lần thử và chặn trong x phút ...

Một bảng cầu vồng sẽ chỉ được sử dụng nếu bạn băm mật khẩu và kẻ tấn công biết băm. Hơn anh ta có thể tìm thấy hàm băm trong bảng cầu vồng nếu nó chỉ là "12345" hoặc một cái gì đó tương tự.

Chỉ để hoàn thành chuyến đi khứ hồi: Để làm cho một bảng cầu vồng trở nên vô dụng, bạn nên muối mật khẩu. Và sử dụng một muối unqiue cho mỗi mật khẩu và không chỉ một cho tất cả. Nếu bạn làm điều đó, kẻ tấn công cần tạo một bảng cầu vồng với muối duy nhất cho mỗi tài khoản mà anh ta muốn truy cập. Khéo léo thực hiện bên cạnh bạn, bạn có thể tăng tốc độ băm bằng thuật toán băm nhiều lần để một thế hệ có thể mất nửa giây. Nếu bạn đã làm điều này, việc truy cập vào một tài khoản trên trang web của bạn phải có giá trị hàng ngày, có thể là tháng tạo băm để tìm một kết quả khớp với tài khoản này ... Tôi không thể nghĩ ra một kẻ tấn công sẽ cố lấy tất cả mật khẩu khi nó sẽ mất nhiều thời gian

Đối với thời gian băm: Hãy suy nghĩ về thời gian chờ đợi 500ms cho một cơ chế đăng nhập. Tôi nghĩ rằng nó có thể chấp nhận được ... (một lời nhắc nhở: gần một giây bắt tay với SSL)