Bạn sẽ làm gì không hợp lệ đối với mật khẩu?

Question

Tình huống giả định: bạn đã triển khai hệ thống xử lý mật khẩu và không áp đặt bất kỳ hạn chế nào đối với những ký tự nào có thể được sử dụng. Bạn muốn thiết lập một số quy tắc thỏa hiệp hợp lý giữa hai điều -

1. Cho phép người dùng tự do càng nhiều càng tốt.
2. Cho phép khả năng bạn có thể thay đổi cách bạn xử lý mật khẩu trong tương lai - bạn không muốn loại trừ việc triển khai hợp lý vì mật khẩu hiện tại của người dùng của bạn sẽ không hợp lệ.

Bạn sẽ áp đặt những quy tắc nào? Có những yếu tố nào khác có thể ảnh hưởng đến lựa chọn của bạn không?

Answer 1

Tốt nhất không có giới hạn nào, trừ khi bạn thực sự có thể biện minh cho họ.

Nếu bạn là ngân hàng, nhà cung cấp email hoặc nếu người dùng có thể đặt hàng gì đó mà không cung cấp thẻ tín dụng, thì buộc người dùng sử dụng mật khẩu mạnh có ý nghĩa. Nếu không, bạn chỉ làm cho nó khó mà không có lý do.

Như những gì bạn nên lưu trữ, tôi muốn nói 1024 ký tự unicode với các ký tự điều khiển bị cấm là về tất cả những gì hợp lý. Nếu người dùng không thể nhập, họ nên chọn một mật khẩu khác. Tất cả các bạn đang lưu trữ là một băm, vì vậy bạn luôn có thể cắt nó xuống bất cứ kích thước nào bạn muốn.

Answer 2

Tôi muốn giữ mọi thứ bạn có thể thực hiện bằng một phím (và tùy ý dịch chuyển) trên bàn phím, ngoại trừ tab. Loại kế hoạch nào sẽ đòi hỏi một lựa chọn hạn chế hơn?

Answer 3

Không áp đặt bất kỳ hạn chế nào. Và có vẻ như với tôi rằng bạn đang lập kế hoạch lưu trữ mật khẩu, chứ không phải là băm. Đừng làm điều đó. Thay vào đó, hãy lưu trữ salt và kết hợp băm mật khẩu và muối nói.

Tuy nhiên, bạn có thể yêu cầu người dùng của mình có mật khẩu mạnh bằng cách áp đặt giới hạn về độ dài (không ít hơn 6 ký tự) và trên các ký tự bao gồm mật khẩu (nói, ký tự phải chứa ký tự chữ cái viết hoa và viết thường) , một hoặc hai chữ số và một số ký tự không phải chữ cái như^hoặC#).

Answer 4

Cho người dùng nhập mật khẩu có chứa ít nhất một số và ký tự không phải chữ số và chữ số và dài hơn sáu ký tự. Dù sao, tôi nghĩ rằng bất kỳ những hạn chế, trong trường hợp bạn thay đổi cách bạn xác nhận mật khẩu, bạn nên thông báo cho người dùng trong thời gian hợp lý để cập nhật của họ.

Answer 5

Bất kỳ ký tự không kiểm soát nào cũng đều ổn. Tôi nên nghĩ rằng các nhà phát triển các hệ thống mật khẩu siêu duper trong tương lai sẽ cho phép các ký tự ASCII "bất thường" như dấu câu và các dấu khác, nhưng các ký tự điều khiển có thói quen khó sử dụng để nhập vào chế độ văn bản và thậm chí cả hộp thoại GUI và Enter/Return để được tự do cho mục đích riêng của họ.

Answer 6

Một không gian trống (dựa trên logic nó có thể được cắt vô tình trước khi được băm)

Answer 7

Các quy tắc tôi sẽ đề nghị thực thi:

1. Chiều dài - không ít hơn 8 ký tự - nhưng không nhiều hơn 20
2. Dễ bị hỏng - thẻ không được chứa tên, họ hoặc tên người dùng của người dùng, cũng không phải (nếu có thể kiểm tra) bất kỳ từ nào xuất hiện trong từ điển tiếng Anh.
3. Nội dung - Có 4 loại ký tự trên bàn phím: chữ hoa, chữ thường, số và dấu chấm câu. Mật khẩu tốt nên bao gồm các đại diện từ ít nhất 3 nhóm và không bao gồm 2-3 ký tự của cùng một nhóm trong một hàng.

Answer 8

Không giới hạn mật khẩu. Nếu họ có thể nhập nó từ bàn phím của họ, bất kể họ sử dụng bàn phím khu vực nào. Bạn có thể muốn áp đặt độ dài tối thiểu, các tùy chọn như ít nhất một số và một ký tự đặc biệt, nhưng không có giới hạn tối đa.

Về câu hỏi thứ hai của bạn. Cách tôi sẽ thực hiện nó là thông qua làm cho các lĩnh vực riêng biệt khi bạn cải thiện sức mạnh mật khẩu. Ví dụ, ngay bây giờ bạn sẽ có hai trường liên quan đến mật khẩu: muối, password_md5. Cho phép nói sau này bạn muốn sử dụng sha256. Tạo một trường mới có tên là password_sha256. Khi người dùng đăng nhập vào bạn trước tiên hãy kiểm tra password_sha256. Nếu trường đó trống thì hãy kiểm tra password_md5. Nếu điều đó phù hợp với bạn bây giờ có mật khẩu văn bản thuần túy mà người dùng đã nhập. Sau đó, bạn có thể tạo mật khẩu sha256 (tôi cũng sẽ đặt lại muối để có biện pháp tốt) và lưu trữ giá trị mới. Sau đó tôi sẽ bỏ trống giá trị trong password_md5 để không ai có thể đảo ngược điều đó để lấy mật khẩu.

Cá nhân tôi chỉ cần sử dụng hàm băm tốt nhất mà ngôn ngữ của bạn có thể thực hiện và sử dụng. Những điều quan trọng là thực thi chính sách mật khẩu tối thiểu tốt - không quan trọng mức độ bảo mật của băm khi mật khẩu là "1234" - và hạt giống băm với một số ký tự ngẫu nhiên để tránh các cuộc tấn công từ điển.

Answer 9

Trong tổ chức của chúng tôi, nếu người dùng cung cấp mật khẩu, chúng tôi cho phép họ sử dụng bất kỳ thứ gì họ muốn.

Khi người dùng đăng ký lần đầu tiên trong hệ thống, mật khẩu được tạo cho họ. Vì mật khẩu này thường được gửi cho họ, chúng tôi tránh sử dụng các ký tự nhất định có thể bị nhầm lẫn, đặc biệt khi sử dụng các phông chữ nhất định. Ví dụ, chữ O và số 0 (không) không được sử dụng. Tương tự cho L, I và 1 (một), S và 5, Z và 2 và những người khác.

Trước khi chúng tôi thực hiện thay đổi này, chúng tôi đã có rất nhiều cuộc gọi đến bộ phận hỗ trợ của chúng tôi bởi vì các nhân vật chúng ta bối rối và họ không thể đăng nhập.

Answer 10

Cá nhân, tôi sử dụng bàn phím vân tay DigitalPersona của (vâng, Microsoft không [hoặc đã thực hiện một thiết bị tương tự, cả được tích hợp hoặc tách biệt với bàn phím).

Điều này cho phép tạo mật khẩu cực kỳ dài và phức tạp mà không cần phải viết xuống (khi nhấn ngón tay của bạn trên đầu đọc cung cấp mật khẩu cho hộp thoại Đăng nhập [system/application/website]).

Điều này, theo ý kiến ​​của tôi, cung cấp tốt nhất của cả hai thế giới: Rất khó để "đoán" mật khẩu, mà không cần phải nhớ chúng. Nó cũng làm cho đơn giản đề nghị bảo mật bổ sung của việc sử dụng mật khẩu khác nhau trên các hệ thống khác nhau.

Vâng, đó là giá trị hai xu của tôi.

Answer 11

Cá nhân tôi luôn quan tâm đến việc không thực thi quá nhiều quy tắc.

Điều này vừa thay đổi. Tôi vừa tìm thấy trang web của tôi dễ bị tấn công XSS. Giải pháp là vệ sinh mọi phần đầu vào đến từ người dùng, bao gồm cả mật khẩu.

Trong 10 năm chúng tôi không có giới hạn về mật khẩu. Bây giờ chúng tôi đang thực hiện một giới hạn cho các ký tự có thể được sử dụng, và điều này chỉ đơn giản là để chặn tin tặc từ việc có thể truy cập Javascript hoặc SQL.Vì vậy, chúng tôi đã tạo danh sách sau:

Ký tự hợp lệ cho mật khẩu là: a-z A-Z 0-9. - _ $ *() # @! %/(trống)

Điều này cho phép rất nhiều tính linh hoạt nhưng tránh các ký tự có thể được sử dụng để mã hóa bản hack XSS, chẳng hạn như; <> \ {} [] + =? &,: ' "`

HTH

Answer 12

Một số quy tắc để làm theo:

1. Tránh kiểm soát nhân vật Nó không phải là phổ biến ngày hôm nay, nhưng ký tự điều khiển tất cả đều có ý nghĩa đặc biệt và một số nhân vật chặn phần cứng điều khiển. Một số sẽ gây ra các vấn đề về dữ liệu Ví dụ Control 0 (Zero) sẽ tạo ra một giá trị rỗng:
2. Bạn sẽ áp dụng các hạn chế về bảo mật? Đây là câu hỏi về giao diện người dùng cũng như vấn đề bảo mật. cần bảo mật. ny của các ví dụ được đưa ra trước đây đã lỗi thời. Bảng băm cho các kết hợp mật khẩu được xuất bản cho tối đa 15 mật khẩu ký tự và 16 mật khẩu ký tự có thể được brute buộc phải withing phút nếu mật khẩu là yếu hoặc theo hành vi của con người điển hình. Bắt đầu bằng vốn, kết thúc bằng số hoặc ký tự đặc biệt.
3. Tôi muốn tránh các ký tự đại diện chung, dấu ngoặc kép, dấu hai chấm, dấu chấm phẩy, v.v. thường được sử dụng trong ngôn ngữ OS hoặc DB.
4. Xác thực đa yếu tố là một cách hay để thực hiện. Không chỉ phụ thuộc vào mật khẩu hoặc không chấp nhận mật khẩu.