Yêu cầu mật khẩu hợp lý và an toàn để đăng ký người dùng là gì?


10

Đây là chính sách mật khẩu tôi vừa nhận được từ UPS (chỉ để kiểm tra trạng thái gói):

Mật khẩu của bạn phải dài từ 8 đến 26 ký tự. Nó phải chứa ít nhất ba trong số các loại ký tự sau: chữ thường, chữ in hoa, chữ số, ký tự đặc biệt hoặc dấu cách. Mật khẩu có thể không chứa ID người dùng, tên của bạn hoặc địa chỉ email của bạn. (SSO_1007)

Tôi thực sự phải vắt óc phần nào để tạo mật khẩu này, nhưng không chỉ vậy, quan trọng nhất, tôi chắc chắn rằng sau 3 ngày tôi sẽ quên mật khẩu này là gì. Người dùng sẽ không được hạnh phúc. Đặt lại mật khẩu có thể thường xuyên. Tôi nghĩ người dùng sẽ cố gắng tránh sử dụng trang web trừ khi họ phải làm vậy.

Chính sách mật khẩu hợp lý và an toàn khi thiết lập trang web là gì? Tôi nghĩ rằng một số công ty có thể sợ một số tin tặc thử mật khẩu từ một triệu lần trở lên, vì vậy họ thêm tất cả các yêu cầu đó cho "ký tự đặc biệt, chữ thường, chữ hoa", nhưng sẽ không hợp lý khi tắt tài khoản hoặc chỉ vô hiệu hóa mật khẩu và yêu cầu đặt lại mật khẩu nếu người dùng đã thử 30 lần hoặc 100 lần? Hoặc, thêm độ trễ 5 giây mỗi lần sau khi người dùng thử 30 lần? Nếu vậy, thì những nhân vật đặc biệt đó sẽ không cần thiết lắm.


1
nếu bạn đặt lại mật khẩu sau 30 trys, bạn chỉ có khả năng gây khó chịu cho những người dùng khác đối với những người xấu (tin tặc / script-kiddys) sẽ khiến mọi thứ trở nên tồi tệ hơn.
oezi

@oezi Ý bạn là, tin tặc có thể làm phiền những người tốt bằng cách chỉ cần đăng nhập 30 lần với một số mật khẩu giả? Điều gì về độ trễ 5 giây sau 30 lần thử tôi vừa thêm?
phân cực

14
Chưa kể rằng tôi không thể thực hiện nghiêm túc độ dài mật khẩu khi nó không cho phép "Sửa pin chính xác cho ngựa".
David Thornley

6
Làm thế nào về phương pháp thứ hai dưới đây trong truyện tranh Xkcd này ?
Robert Harvey

6
Xin chào, đây có thể là một câu hỏi hay hơn cho một trang web chị em, Bảo mật CNTT , nhưng nó đã được hỏi và trả lời ở đó dưới nhiều hình thức khác nhau. Kiểm tra các câu hỏi như thế này hoặc để biết thêm thông tin về bối cảnh xung quanh bình luận của Robert Harvey, hãy xem câu hỏi này .

Câu trả lời:


15

Thành thật mà nói, tôi thấy việc yêu cầu mật khẩu nghiêm ngặt là một sự phiền toái và không phải là một lợi ích. Tôi muốn nói như một quy tắc hợp lý nhất là chỉ xác định độ dài, có thể là các ký tự đặc biệt + chữ và số. Bất cứ điều gì nhiều hơn là yêu cầu mọi người ghi lại mật khẩu của họ, điều này đánh bại toàn bộ mục đích của việc có mật khẩu an toàn. Tôi cũng ghét phải thay đổi mật khẩu của mình mỗi x ngày với bộ quy tắc vô lý thông thường (ví dụ: không thể sử dụng lại 25 mật khẩu cuối cùng) - một lần nữa, tất cả những điều đó là buộc mọi người phải viết ra để họ không quên, tại điểm nào bạn có thể không yêu cầu mật khẩu.


4
Viết mật khẩu không đánh bại mục đích. Nếu tôi có một mật khẩu thực sự phức tạp được viết trên một bài đăng - nó bị kẹt trên màn hình của tôi thì cách duy nhất để ai đó có thể truy cập vào tài khoản của tôi là nếu họ đột nhập vào nhà tôi và ngồi ở bàn làm việc của tôi. Trong tình huống này, tôi có một vấn đề lớn hơn rất nhiều so với việc ai đó có thể theo dõi việc giao hàng UPS của tôi.
Qwerky

2
Điều gì xảy ra nếu đó là chính sách của công ty và đồng nghiệp tìm thấy mật khẩu của ai đó? Thiệt hại vẫn có thể được gây ra và chính sách mật khẩu được cho là an toàn sẽ không giúp được gì nếu nó phức tạp đến mức hầu hết mọi người chỉ đăng nó lên màn hình để bất kỳ ai đi ngang qua cũng có thể tìm thấy mật khẩu của họ cho dữ liệu của công ty.
Wayne Molina

2
+1, tôi hoàn toàn đồng ý với Wayne. Một phần lớn, nếu không phải là phần lớn các mối đe dọa an ninh đến từ 'bên trong'. Các chính sách buộc người dùng cuối cùng phải ghi lại mật khẩu hoàn toàn đánh bại mục đích.
GrandmasterB

1
Chưa kể đến việc bạn có thể làm phiền người dùng nếu họ cần nghĩ ra một số mật khẩu quá phức tạp để phù hợp với các quy tắc.
Mavrik

1
@mouviciel Tôi tin tưởng nó đủ để đặt những thứ như ví và điện thoại của tôi vào đó, thứ mà tôi coi trọng hơn hầu hết mọi tài khoản trực tuyến tôi có.
Qwerky

13

Ý kiến ​​của tôi là mật khẩu chỉ nên có một yêu cầu về độ dài. Bạn không muốn ai đó nhập "a" làm mật khẩu của họ. Và như câu trả lời xkcd cho thấy, một mật khẩu cực kỳ khó nhớ không phải lúc nào cũng an toàn. Luôn luôn cho phép mọi người thay đổi mật khẩu của họ là tốt. Và quên đi "bạn không thể sử dụng bất kỳ ký tự nào có trong mật khẩu trước đó".

Làm một chính sách mật khẩu tục tĩu sẽ gây hại nhiều hơn là tốt. Ở trường đại học, tôi đã tìm đến chính sách mật khẩu tương tự như chính sách của UPS VÀ bạn phải thay đổi nó cứ sau 2 tuần VÀ bạn không thể sử dụng 50 mật khẩu trước đó bạn đã sử dụng. Vì vậy, những gì giáo viên của tôi khuyến nghị khi thiết lập tài khoản cho chúng tôi là sử dụng mật khẩu thông thường của chúng tôi tuân thủ các quy tắc và thêm một bộ đếm vào cuối của mật khẩu và đưa vào mật khẩu của bạn gợi ý số truy cập là gì.

Ngoài ra, chính sách mật khẩu nghiêm ngặt sẽ không làm bất cứ điều gì bất cứ khi nào cơ sở dữ liệu văn bản đơn giản của bạn bị hack bởi lỗi tiêm SQL ... hoặc bạn gửi email mật khẩu cho người dùng của mình và nó bị chặn ..

Về cơ bản, đừng biến hệ thống mật khẩu của bạn thành rắc rối cho người dùng của bạn hoặc nó sẽ khuyến khích họ làm những việc không an toàn để họ có thể làm việc xung quanh nó. Chẳng hạn, công ty của tôi khi nhận được một máy chủ chuyên dụng từ một trung tâm dữ liệu, họ đã thiết lập cho chúng tôi mật khẩu dài 20 ký tự. Họ quá an toàn để gửi email cho chúng tôi và phải fax. Chúng tôi không thể thay đổi mật khẩu, chỉ yêu cầu tạo mật khẩu 20 ký tự mới. Và đó là cách này cho mọi người dùng ... vì vậy những gì chúng tôi đã làm chỉ là tạo một tài liệu văn bản trên máy tính để bàn bằng mật khẩu. Ngoài ra, chúng tôi không sử dụng chúng nữa vì đối với tất cả "bảo mật" mà chúng có, chúng thực sự khá không an toàn.


Chưa kể rằng nếu bạn tạo một mật khẩu đủ khó để nhớ, người dùng của bạn sẽ chuyển sang bảng ghi chú dán trên bàn của họ. Mật khẩu "an toàn" khiến mọi người đều mở một cách thảm hại đối với kỹ thuật xã hội không an toàn.
Fomite

4

Hãy chắc chắn để cho phép không gian. Mọi người tôi biết đều có thể gõ các cụm từ ngắn nhanh hơn họ có thể gõ chữ cái đầu tiên của mỗi từ trong cụm từ. Ví dụ: thử gõ Bird in a Treevà sau đó BiaT. Điều này có lợi thế là nếu bạn viết một cụm từ thích hợp làm việc mơ hồ như pick Up milkhoặc Meetings all daytrên một ghi chú dán, thì đó rõ ràng không phải là mật khẩu.

Tôi không phải là một fan hâm mộ lớn của quy tắc "bạn phải có số và ký hiệu", nhưng nếu bạn áp dụng chúng một cách nhất quán (ví dụ: tôi luôn là 1, a luôn là @) thì bạn vẫn có thể viết cụm từ tiếng Anh trên dính, áp dụng các quy tắc chỉ biết đến bạn nói và nhập B1rd in @ treevào hộp thoại mật khẩu. Từ quan điểm bảo mật, các con số và biểu tượng không thêm nhiều, nhưng chúng không cần làm bạn phát điên.

Các trang web có độ dài mật khẩu tối đa khiến tôi tức giận nếu cụm từ hay của tôi bị coi là "quá dài". 26 có vẻ hợp lý. Tôi hiểu ai đó phải thiết kế chiều rộng của cột, nhưng 12 chỉ là ngắn một cách ngu ngốc.


1
Điều này rất thông minh. Sử dụng một cụm từ ngày evey khoảng cách ... Thông minh. Mặc dù tôi sẽ sử dụng hệ thống mật khẩu mạnh phổ biến của mình với số và chữ cái được thêm tùy thuộc vào dịch vụ tôi đang đăng nhập. Chỉ tôi biết cách tạo các mật khẩu đó và nó luôn giống nhau nhưng mật khẩu kết quả rất khác nhau (không phải luôn luôn khác nhau nhưng tôi không quan tâm nhiều về những bản sao hiếm hoi đó).
Robert Koritnik

1
Chiều rộng của cột nào? Các hộp văn bản thường có cuộn nội bộ và nếu bạn đang lưu mật khẩu văn bản gốc trong DB thì bạn đang làm sai.
Peter Taylor

Dbs bây giờ rẻ. Với khả năng hấp thụ tốt nếu bạn cho phép mật khẩu dài 50 char, độ rộng của db sẽ là 110 max (chính xác là 102). Nhưng tôi sẽ làm cho nó 150 varchar ... thiết kế db tốt có nghĩa là không có bảng nào có nhiều hơn 20 cột, vì vậy điều này sẽ không gây ra vấn đề lớn nào.
tgkprog

2

An toàn so với thuận tiện

Chính sách bảo mật của mật khẩu phải phù hợp với chi phí thỏa hiệp. Nếu trang web của bạn đứng trước tài khoản tài chính của tôi, tôi muốn bảo vệ mật khẩu nghiêm ngặt. Nếu đó là một trang web dành cho người hâm mộ thích hợp về Autobots, bạn không cần bảo vệ nhiều.

Các quy tắc của UPS là hợp lý ngoại trừ:

  • Độ dài tối đa là quá nhỏ. Bạn nên tạo điều kiện cho việc sử dụng cụm mật khẩu dễ nhớ hơn và có thể an toàn hơn.

Tôi đã không thấy thiết lập lại sau số lần thử X trong các quy tắc được trích dẫn, tôi nghĩ rằng điều này là ngớ ngẩn trong hầu hết các trường hợp. Tôi nghĩ tốt hơn hết là bạn nên khóa ai đó trong một khoảng thời gian, thay vì buộc phải thiết lập lại. Điều này ngụ ý một mức độ bảo mật nhất định. Nếu điều đó là không cần thiết, thì nó không và khóa / đặt lại là một điểm cần thiết.

Có nhiều quy tắc chính sách mật khẩu có lợi ích bảo mật cận biên tốt nhất. Tuy nhiên, cũng có những quy tắc có lợi ích thực sự, hữu hình đối với việc bảo mật mật khẩu của bạn.

Quy tắc (và lý do):

  • chiều dài tối thiểu

Ngăn chặn một thử nghiệm kết hợp và tấn công lỗi sẽ nhanh chóng phá vỡ mật khẩu rất ngắn.

  • khởi kiện không sử dụng một từ tiếng Anh duy nhất (hoặc bất kỳ ngôn ngữ nào khác)

Điều này ngăn chặn các cuộc tấn công từ điển.

  • bắt buộc bao gồm các loại khác nhau (ví dụ: trường hợp hỗn hợp, số, dấu chấm câu)

Điều này làm tăng không gian tấn công trung bình.

Tất cả những lý do này có thể được theo dõi để giảm thiểu sự thiên vị của người dùng trong việc chọn mật khẩu. Hầu hết người dùng đều thiên về việc tạo mật khẩu ngắn hơn, dễ nhớ. Thật không may, điều đó thường làm cho mật khẩu dễ dàng bị tấn công hơn. Những gì hầu hết người dùng cần là hướng dẫn về cách tạo mật khẩu dễ nhớ an toàn hoặc cụm mật khẩu dài hơn.

Mật khẩu đáng nhớ an toàn

Khi tôi cần tạo một mật khẩu có giới hạn độ dài, tôi luôn bắt đầu bằng một cụm từ để tôi có một bản ghi nhớ. Tôi lấy cụm từ và tôi nhận được cùng một ký tự vị trí từ mỗi từ. Bây giờ tôi có một chuỗi chỉ các nhân vật. Sau đó tôi chọn viết hoa, một số dựa trên tên riêng trong cụm từ hoặc theo mẫu (đầu tiên và cuối cùng, mỗi chữ cái khác, v.v.). Sau đó tôi thêm dấu chấm câu và số dựa trên một số quy tắc hoặc mẫu tùy ý. (ví dụ: tất cả 'j là 7, sử dụng' & 'trong đó có một' và 'trong cụm từ, v.v.).

Mẹ ơi, vừa giết một người đàn ông. Đặt súng vào đầu anh ta. Kéo cò của tôi, bây giờ anh ta đã chết.

Cụm từ được cung cấp bởi Queen

  1. mjkampagahhpmtnhd - chữ cái đầu tiên của mỗi từ
  2. MjkamPagahhPmtnhd - vỏ khớp với cụm từ
  3. Mjk0mP0g0hhPmtnhd - đã thay đổi 'a' thành 0
  4. Mjk0mP0g0 () Pmtnhd - đã đổi 'đầu' thành ()

Sau khi tôi gõ nó vài lần khi nghĩ cụm từ tôi sẽ không bao giờ gặp vấn đề gì khi nhớ.


1
Vấn đề thực sự là tài khoản UPS sẽ được sử dụng bởi hàng tá người trong công ty. Khóa tất cả chúng lại vì Fred vận chuyển nhầm, nó sẽ gây ra 1, hỗn loạn 2, mọi người chuyển sang FedEx
Martin Beckett

2
Tôi nghĩ vấn đề là các chính sách mật khẩu đáng ghét không làm tăng tính realbảo mật (chúng chỉ tăng nhận thức về bảo mật) và thực sự có thể gây hại cho bảo mật.
Martin York

@Martin Beckett: 1) Đối với các môi trường sử dụng chính sách khóa nên có và thường có các cách khác để mở khóa ngay mật khẩu của bạn 2) Mỗi ​​người nên có tài khoản riêng 3) Bảo mật B2B thường được thực hiện tốt hơn thông qua các hệ thống khóa công khai như PKCS mà không phải sử dụng mật khẩu.
dietbuddha

@Loki Astari: Vâng, điều đó đúng với một chính sách đáng ghét, câu hỏi đặt ra là các quy tắc nào làm cho chính sách trở nên đáng ghét với bối cảnh của nó. Ví dụ tôi nghĩ rằng cả hai chúng ta có thể đồng ý về yêu cầu độ dài tối thiểu là hợp lý. Tôi chắc chắn đồng ý bất kỳ yêu cầu nào bao gồm việc giữ lịch sử mật khẩu của bạn là đáng ghét vì nó không làm tăng tính bảo mật.
dietbuddha

3
Ý tưởng của bạn ở trên có vẻ hợp lý nhưng trong thực tế, bạn đang đánh bại chính mình xkcd.com/936 . Tôi có thể không đồng ý với ba trong số 4 điểm của bạn và sẽ đề nghị rằng tất cả những điều này dẫn đến việc lấy mật khẩu dễ dàng hơn. (Độ dài là dương duy nhất). Mật khẩu tốt nhất sẽ là:Mama, just killed a man.
Martin York

1

Mật khẩu của bạn phải dài từ 8 đến 26 ký tự

Mật khẩu tối thiểu dài 8 ký tự là một di sản của Lan Manager. Lan Manager đã băm mật khẩu bằng cách chia chúng thành 2 chuỗi 7 ký tự, sau đó băm chúng. Bằng cách yêu cầu tối thiểu 8 ký tự, họ đảm bảo rằng từ thứ 2 không giống với mật khẩu trống (không có muối, vì vậy mọi trường hợp của 7 khoảng trống được băm cho cùng một kết quả).

Tôi chắc chắn rằng sau 3 ngày tôi sẽ quên mật khẩu này là gì.

Tôi đã từ bỏ, các quy tắc rất ngớ ngẩn và lố lăng đến nỗi tôi viết chúng xuống ngay bây giờ. Tất cả ngoại trừ số ít tôi sử dụng cho các trang web. Chủ nhân hiện tại của tôi cũng theo dõi 24 mật khẩu đã sử dụng để chúng không thể được tái chế, mật khẩu cũng không thể chứa bất kỳ từ tiếng Anh nào trên 3 ký tự (tiến hoặc lùi). Nó cũng làm cho chắc chắn rằng bạn không sử dụng một từ trước đó và tăng một số số như là một phần của nó (vì vậy nếu P4ssw0rd1được sử dụng, bạn không thể sử dụng P4ssw0rd2, và cũng không P4ssw0rd0).

Tôi đã học được bài học của mình một cách khó khăn tại văn phòng khi tôi phải thay đổi mật khẩu, phải mất 45 phút để hệ thống chấp nhận thay thế, sau đó nhanh chóng quên những gì tôi đã đưa ra và phải đặt lại và lãng phí 45 vài phút cố gắng để có được một cái gì đó tôi có thể nhớ là đủ phức tạp để đáp ứng các yêu cầu (một số yêu cầu được liệt kê ở trên, một số không và một số tôi không biết). Sẽ không có nhiều niềm vui khi cố gắng đưa ra một cái gì đó đáp ứng các quy tắc mà bạn không được phép biết. Ít nhất là với các trò chơi như Mastermind, bạn sẽ được cung cấp manh mối về mức độ gần gũi của bạn. Tại văn phòng, một số người có thể sử dụng thẻ thông minh , tôi không phải là một trong số họ.


1

Sử dụng bcrypt khi lưu trữ mật khẩu là một khởi đầu tốt, đơn giản vì nó làm cho các nỗ lực hack vũ phu không thể thực hiện được.


0

Hợp lý và an toàn là loại trừ lẫn nhau. Chúng là hai đầu của một thanh. Tạo sự cân bằng ở giữa sẽ là tốt nhất. Để hướng tới sự an toàn và mọi người ghi lại mật khẩu hoặc sử dụng tính năng mở khóa mật khẩu hoàn toàn không an toàn.

Ví dụ trên dường như nghiêng về an toàn hơn là hợp lý. Tôi đã thấy tồi tệ hơn.

Tôi thích nghiêng về phía hợp lý. Điều quan trọng là nghiêng về phía an toàn trong back-end của bạn. Lưu trữ ít nhất có thể sử dụng muối, vv Tất cả các phương pháp được đề xuất mới nhất để mã hóa mật khẩu vào cơ sở dữ liệu của bạn và cũng mã hóa chúng theo một cách. Sau đó giữ cơ sở dữ liệu của bạn và mã của bạn an toàn. Đồng thời đào tạo bất cứ ai có quyền quản trị cho hệ thống của bạn mà họ cần sử dụng mật khẩu bảo mật duy nhất. Gần đây, nó đã được chỉ ra rằng việc xâu chuỗi nhiều từ trong từ điển lại an toàn hơn so với việc kéo theo các ký tự và trường hợp đặc biệt. Nó yêu cầu các từ điển ghép phù hợp thực sự tăng thêm thời gian cho tin tặc, tuy nhiên, những điều này vẫn đáng nhớ đối với người dùng.


1
Lý do và bảo mật không phản đối các khái niệm. Họ có thể xung đột, nhưng thường có thể đưa ra một cái gì đó hợp lý an toàn và có thể sử dụng hợp lý. Nó có thể đòi hỏi một chút suy nghĩ sáng tạo và không thể được đo lường đầy đủ trong danh sách kiểm tra, đó có thể là lý do tại sao nó không được nhìn thấy ở nhiều nơi.
David Thornley

Có rất nhiều lịch sử nơi hợp lý và bảo mật ở hai đầu đối diện. Bạn có thể cho phép người dùng có mật khẩu hợp lý (không cần kiểm tra, bất cứ điều gì xảy ra) và đó có lẽ là kém an toàn nhất hoặc có thể không có mật khẩu thậm chí kém an toàn hơn. Microsoft đã học được điều này một cách khó khăn. Mọi người muốn email tốt hơn, vì vậy họ quyết định cho phép kịch bản như trong word, sau đó xuất hiện virus email. Đó là một trận chiến kể từ đó. Bạn không thể có email kích hoạt web (hợp lý) mà không phải chịu rủi ro bảo mật
Bill Leeper

Chắc chắn, thật dễ dàng để dễ sử dụng và bảo mật đối lập, nếu bạn không có lựa chọn tốt. Rất nhiều sự lựa chọn của Microsoft có thể trở lại vào năm 2005 và trước đó được đưa ra rõ ràng là không có mắt để bảo mật.
David Thornley

Xin vui lòng, đưa ra một ví dụ mà bạn dễ sử dụng VÀ bảo mật. Tôi đã làm việc rất nhiều nơi và thực hiện rất nhiều hệ thống an toàn và vẫn chưa thấy điều này. Và đây sẽ là một ứng dụng web thông thường, không phải là sử dụng phím .ssh để truy cập hệ thống từ xa. Bà tôi cần có thể làm điều này trên hệ thống Windows Vista của mình :-)
Bill Leeper

Xem xét cụm mật khẩu, chẳng hạn như xkcd gần đây. An toàn hơn hầu hết các mật khẩu, thường dễ nhớ hơn mật khẩu tốt và thường xuyên trên 26 ký tự mà trang web cho phép.
David Thornley

0

Không phải là một từ trong từ điển, hoặc một biến thể tầm thường của nó. Đó là nó. Một bó gồm hai từ trong từ điển là khá nhiều không thể bẻ khóa. Một thay thế một chữ cái cho một ký tự không phải là một thay thế rõ ràng (0-O, 1-I, 5-S) quá.

Ngoài ra, nếu bạn giới hạn thời gian phản hồi - mật khẩu được chấp nhận / bị từ chối sau 1 giây và không có hai lần thử song song nào cho cùng một lần đăng nhập - người ta phải kết thúc (OK hoặc lỗi) trước khi bạn thử một chữ cái khác, không có chữ cái 6 chữ cái không từ điển mật khẩu đặc biệt sẽ mất 9 năm để phá vỡ.


0

Sự phức tạp của yêu cầu mật khẩu nên được cân bằng với nội dung của các trang web của bạn. Một ngân hàng nên yêu cầu mật khẩu rất phức tạp (chữ hoa, chữ thường, số và ký tự đặc biệt). Tuy nhiên, nếu nội dung không quan trọng, như các tìm kiếm đã lưu và số theo dõi, yêu cầu mật khẩu nên được nới lỏng. Độ dài tối thiểu 6 ký tự là đủ. Nếu không, nó chỉ đơn giản sẽ gây khó chịu cho khán giả của bạn và ngăn cản họ tạo ra một đăng nhập.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.