Tôi có nên áp đặt độ dài tối đa cho mật khẩu?

Tôi có thể hiểu rằng việc áp dụng độ dài tối thiểu cho mật khẩu có ý nghĩa rất lớn (để cứu người dùng khỏi chính họ), nhưng ngân hàng của tôi có một yêu cầu là mật khẩu dài từ 6 đến 8 ký tự và tôi bắt đầu tự hỏi ...

• Điều này sẽ không làm cho nó dễ dàng hơn cho các cuộc tấn công vũ phu? (Xấu)
• Điều này có nghĩa là mật khẩu của tôi đang được lưu trữ không được mã hóa? (Xấu)

Nếu ai đó với (hy vọng) một số chuyên gia bảo mật CNTT giỏi làm việc cho họ đang áp đặt độ dài mật khẩu tối đa, tôi có nên nghĩ về việc làm tương tự không? Những ưu / nhược điểm của việc này là gì?

Mật khẩu được băm thành 32, 40, 128, bất kỳ độ dài nào. Lý do duy nhất cho độ dài tối thiểu là để ngăn mật khẩu dễ đoán. Không có mục đích cho một chiều dài tối đa.

XKCD bắt buộc giải thích lý do tại sao bạn làm cho người dùng của mình không hài lòng nếu bạn áp đặt độ dài tối đa:

Độ dài tối đa được chỉ định trên trường mật khẩu phải được đọc dưới dạng CẢNH BÁO BẢO MẬT . Bất kỳ người dùng có ý thức, bảo mật nào cũng phải thừa nhận điều tồi tệ nhất và mong đợi rằng trang web này đang lưu trữ mật khẩu của bạn theo nghĩa đen (nghĩa là không được băm, như được giải thích bởi epochwolf).

Trong đó là trường hợp:

1. Tránh sử dụng trang web này như bệnh dịch hạch nếu có thể. Họ rõ ràng không biết gì về an ninh.
2. Nếu bạn thực sự phải sử dụng trang web, hãy đảm bảo mật khẩu của bạn là duy nhất - không giống như bất kỳ mật khẩu nào bạn sử dụng ở nơi khác.

Nếu bạn đang phát triển một trang web chấp nhận mật khẩu, đừng đặt giới hạn mật khẩu ngớ ngẩn, trừ khi bạn muốn nhận được tarred với cùng một bàn chải.

[Trong nội bộ, tất nhiên mã của bạn chỉ có thể coi các byte 256/1024 / 2k / 4k / (bất cứ thứ gì) là "đáng kể", để tránh bị bẻ khóa mật khẩu voi ma mút.]

Cho phép độ dài mật khẩu hoàn toàn không bị ràng buộc có một nhược điểm lớn nếu bạn chấp nhận mật khẩu từ các nguồn không đáng tin cậy.

Người gửi có thể cố gắng cung cấp cho bạn một mật khẩu dài đến mức dẫn đến việc từ chối dịch vụ cho người khác. Ví dụ: nếu mật khẩu là 1GB dữ liệu và bạn dành toàn bộ thời gian để chấp nhận nó cho đến khi hết bộ nhớ. Bây giờ giả sử người này gửi cho bạn mật khẩu này nhiều lần bạn sẵn sàng chấp nhận. Nếu bạn không cẩn thận về các thông số khác có liên quan, điều này có thể dẫn đến một cuộc tấn công DoS.

Đặt giới hạn trên cho thứ gì đó như 256 ký tự dường như quá hào phóng theo tiêu chuẩn ngày nay.

Đầu tiên, đừng cho rằng các ngân hàng có các chuyên gia bảo mật CNTT giỏi làm việc cho họ. Rất nhiều không .

Điều đó nói rằng, chiều dài mật khẩu tối đa là vô giá trị. Nó thường yêu cầu người dùng tạo một mật khẩu mới (tranh luận về giá trị của việc sử dụng các mật khẩu khác nhau trên mỗi trang web vào lúc này), điều này làm tăng khả năng họ sẽ viết chúng xuống. Nó cũng làm tăng đáng kể tính dễ bị tấn công, bởi bất kỳ vectơ nào từ lực lượng vũ phu đến kỹ thuật xã hội.

Đặt độ dài mật khẩu tối đa dưới 128 ký tự hiện không được khuyến khích bởi Bảng cheat xác thực OWASP

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Trích dẫn toàn bộ đoạn văn:

Mật khẩu dài hơn cung cấp sự kết hợp nhiều ký tự hơn và do đó khiến kẻ tấn công khó đoán hơn.

Độ dài tối thiểu của mật khẩu nên được thực thi bởi ứng dụng. Mật khẩu ngắn hơn 10 ký tự được coi là yếu ([1]). Mặc dù việc thực thi độ dài tối thiểu có thể gây ra vấn đề với việc ghi nhớ mật khẩu giữa một số người dùng, các ứng dụng nên khuyến khích họ đặt cụm mật khẩu (câu hoặc kết hợp các từ) có thể dài hơn nhiều so với mật khẩu thông thường và dễ nhớ hơn nhiều.

Độ dài mật khẩu tối đa không nên được đặt quá thấp, vì nó sẽ ngăn người dùng tạo cụm mật khẩu. Độ dài tối đa thông thường là 128 ký tự. Cụm mật khẩu ngắn hơn 20 ký tự thường được coi là yếu nếu chúng chỉ bao gồm các ký tự Latin viết thường. Mỗi nhân vật đều có giá trị !!

Đảm bảo rằng mọi ký tự mà người dùng nhập vào thực sự được bao gồm trong mật khẩu. Chúng tôi đã thấy các hệ thống cắt ngắn mật khẩu với độ dài ngắn hơn so với những gì người dùng cung cấp (ví dụ: cắt ngắn ở 15 ký tự khi họ nhập 20). Điều này thường được xử lý bằng cách đặt độ dài của TẤT CẢ các trường nhập mật khẩu chính xác bằng cùng độ dài với mật khẩu độ dài tối đa. Điều này đặc biệt quan trọng nếu độ dài mật khẩu tối đa của bạn ngắn, như 20-30 ký tự.

Một lý do tôi có thể tưởng tượng để thực thi độ dài mật khẩu tối đa là nếu giao diện phải có giao diện với nhiều phụ trợ hệ thống cũ, một trong số đó tự thực thi độ dài mật khẩu tối đa.

Một quá trình suy nghĩ khác có thể là nếu người dùng bị buộc phải sử dụng một mật khẩu ngắn, họ có nhiều khả năng phát minh ra sự vô nghĩa ngẫu nhiên hơn là một cụm từ hoặc biệt danh dễ hiểu (bởi bạn bè / gia đình của họ). Cách tiếp cận này tất nhiên chỉ hiệu quả nếu frontend thực thi việc trộn số / chữ cái và từ chối mật khẩu có bất kỳ từ nào trong từ điển, kể cả các từ được viết bằng l33t-speak.

Một lý do có khả năng hợp lệ để áp đặt một số độ dài mật khẩu tối đa là quá trình băm nó (do sử dụng chức năng băm chậm như bcrypt) chiếm quá nhiều thời gian; một cái gì đó có thể bị lạm dụng để thực hiện một cuộc tấn công DOS chống lại máy chủ.

Sau đó, một lần nữa, các máy chủ nên được cấu hình để tự động loại bỏ các trình xử lý yêu cầu mất quá nhiều thời gian. Vì vậy, tôi nghi ngờ đây sẽ là một vấn đề.

Tôi nghĩ rằng bạn rất đúng trên cả hai gạch đầu dòng. Nếu họ đang lưu trữ mật khẩu được băm, như họ nên, thì độ dài mật khẩu sẽ không ảnh hưởng đến lược đồ DB của họ. Có một độ dài mật khẩu kết thúc mở sẽ ném vào một biến nữa mà kẻ tấn công vũ phu phải tính đến.

Thật khó để thấy bất kỳ lý do nào để giới hạn độ dài mật khẩu, bên cạnh thiết kế xấu.

Lợi ích duy nhất tôi có thể thấy với độ dài mật khẩu tối đa là loại bỏ nguy cơ tấn công tràn bộ đệm do mật khẩu quá dài, nhưng có nhiều cách tốt hơn để xử lý tình huống đó.

Bỏ qua những người nói không xác nhận mật khẩu dài. Owasp theo nghĩa đen nói rằng 128 ký tự là đủ. Chỉ cần cung cấp đủ không gian hơi thở, bạn có thể nói thêm một chút, nói 300, 250, 500 nếu bạn cảm thấy thích nó.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Lpm

Mật khẩu Độ dài Mật khẩu dài hơn cung cấp sự kết hợp nhiều ký tự hơn và do đó khiến kẻ tấn công khó đoán hơn.

...

Độ dài mật khẩu tối đa không nên được đặt quá thấp, vì nó sẽ ngăn người dùng tạo cụm mật khẩu. Độ dài tối đa thông thường là 128 ký tự . Cụm mật khẩu ngắn hơn 20 ký tự thường được coi là yếu nếu chúng chỉ bao gồm các ký tự Latin viết thường.

Lưu trữ là giá rẻ, tại sao giới hạn chiều dài mật khẩu. Ngay cả khi bạn đang mã hóa mật khẩu thay vì chỉ băm nó, chuỗi 64 ký tự sẽ không mất nhiều hơn chuỗi 6 ký tự để mã hóa.

Có thể hệ thống ngân hàng đang phủ lên một hệ thống cũ hơn nên họ chỉ có thể cho phép một lượng không gian nhất định cho mật khẩu.

Ngân hàng của tôi cũng làm điều này. Nó được sử dụng để cho phép bất kỳ mật khẩu, và tôi có một ký tự 20 ký tự. Một ngày nọ, tôi đã thay đổi nó, và lo rằng nó đã cho tôi tối đa là 8 và đã cắt bỏ các ký tự không phải là chữ và số có trong mật khẩu cũ của tôi. Không có ý nghĩa gì với tôi.

Tất cả các hệ thống back-end tại ngân hàng đều hoạt động trước đây khi tôi đang sử dụng mật khẩu 20 ký tự của mình với số không phải là số alpha, vì vậy hỗ trợ kế thừa không thể là lý do. Và ngay cả khi đó là, họ vẫn nên cho phép bạn có mật khẩu tùy ý, và sau đó tạo một hàm băm phù hợp với yêu cầu của các hệ thống cũ. Tốt hơn hết, họ nên sửa chữa các hệ thống cũ.

Một giải pháp thẻ thông minh sẽ không tốt với tôi. Tôi đã có quá nhiều thẻ vì nó ... Tôi không cần một mánh lới quảng cáo khác.

Nếu bạn chấp nhận một mật khẩu có kích thước tùy ý thì người ta sẽ giả sử rằng nó đang bị cắt ngắn theo chiều dài màn vì lý do hiệu suất trước khi nó được băm. Vấn đề với việc cắt ngắn là khi hiệu suất máy chủ của bạn tăng theo thời gian, bạn không thể dễ dàng tăng chiều dài trước khi cắt vì hàm băm của nó rõ ràng sẽ khác. Tất nhiên bạn có thể có một giai đoạn chuyển tiếp trong đó cả hai độ dài được băm và kiểm tra nhưng điều này sử dụng nhiều tài nguyên hơn.

Cố gắng không áp đặt bất kỳ giới hạn trừ khi cần thiết. Được cảnh báo: nó có thể và sẽ cần thiết trong rất nhiều trường hợp khác nhau. Đối phó với các hệ thống di sản là một trong những lý do này. Hãy chắc chắn rằng bạn đã kiểm tra tốt trường hợp mật khẩu rất dài (hệ thống của bạn có thể xử lý mật khẩu dài 10MB không?). Bạn có thể gặp phải các sự cố từ chối dịch vụ (DoS) vì Chức năng phân tách khóa (KDF) bạn sẽ sử dụng (thường là PBKDF2, bcrypt, scrypt) sẽ tốn nhiều thời gian và tài nguyên. Ví dụ thực tế: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-securance/

Có nên có một chiều dài tối đa? Đây là một chủ đề gây tò mò trong CNTT ở chỗ, mật khẩu dài hơn thường khó nhớ hơn và do đó có nhiều khả năng bị ghi lại (LỚN không-không vì lý do rõ ràng). Mật khẩu dài hơn cũng có xu hướng bị lãng quên nhiều hơn, trong khi không nhất thiết là rủi ro bảo mật, có thể dẫn đến rắc rối hành chính, mất năng suất, v.v. Các quản trị viên tin rằng những vấn đề này đang gây áp lực có thể áp dụng độ dài tối đa cho mật khẩu.

Cá nhân tôi tin vào vấn đề cụ thể này, cho mỗi người dùng của riêng họ. Nếu bạn nghĩ rằng bạn có thể nhớ mật khẩu 40 ký tự, thì tất cả sẽ tiếp thêm sức mạnh cho bạn!

Tuy nhiên, mật khẩu đang nhanh chóng trở thành một chế độ bảo mật lỗi thời, Thẻ thông minh và xác thực chứng chỉ chứng minh rất khó để không thể ép buộc như bạn đã nêu là một vấn đề và chỉ một khóa công khai được lưu trữ trên máy chủ kết thúc với riêng tư chìa khóa trên thẻ / máy tính của bạn mọi lúc.

Mật khẩu dài hơn, hoặc cụm từ, khó bị bẻ khóa đơn giản dựa trên độ dài và dễ nhớ hơn là yêu cầu mật khẩu phức tạp.

Có lẽ tốt nhất để đi cho một chiều dài tối thiểu (10+) khá dài, hạn chế độ dài vô dụng.

Các hệ thống kế thừa (đã được đề cập) hoặc can thiệp vào các hệ thống của nhà cung cấp bên ngoài có thể cần đến nắp 8 ký tự. Nó cũng có thể là một nỗ lực sai lầm để cứu người dùng khỏi chính họ. Hạn chế nó theo cách đó sẽ dẫn đến quá nhiều mật khẩu pssw0rd1, pssw0rd2, v.v. trong hệ thống.

Một lý do mật khẩu có thể không được băm là thuật toán xác thực được sử dụng. Ví dụ, một số thuật toán phân loại yêu cầu phiên bản mật khẩu của máy chủ tại máy chủ vì cơ chế xác thực liên quan đến cả máy khách và máy chủ thực hiện cùng một phép toán trên mật khẩu đã nhập (thường không tạo ra cùng một đầu ra mỗi lần như mật khẩu được kết hợp với một 'nonce' được tạo ngẫu nhiên, được chia sẻ giữa hai máy).

Thường thì điều này có thể được tăng cường vì phần tiêu hóa có thể được tính một phần trong một số trường hợp, nhưng không phải lúc nào cũng vậy. Một cách tốt hơn là mật khẩu được lưu trữ bằng mã hóa đảo ngược - điều này có nghĩa là các nguồn ứng dụng cần được bảo vệ vì chúng sẽ chứa khóa mã hóa.

Digst auth có mặt để cho phép xác thực qua các kênh không được mã hóa. Nếu sử dụng SSL hoặc một số mã hóa toàn kênh khác, thì không cần phải sử dụng cơ chế xác thực, nghĩa là mật khẩu có thể được lưu trữ băm thay thế (vì mật khẩu có thể được gửi qua văn bản một cách an toàn (đối với giá trị an toàn nhất định).

Chỉ cần 8 char mật khẩu dài âm thanh đơn giản là sai. Nếu phải có một giới hạn, thì ít nhất 20 char là ý tưởng tốt hơn.

Tôi nghĩ rằng giới hạn duy nhất nên được áp dụng giống như giới hạn 2000 chữ cái, hoặc một cái gì đó khác chắc chắn cao, nhưng chỉ để giới hạn kích thước cơ sở dữ liệu nếu đó là một vấn đề