Tôi có nên buộc người dùng của mình thay đổi mật khẩu mỗi n ngày / tuần / tháng không?

Câu hỏi nói lên tất cả. Chúng tôi đang thiết kế một hệ thống trong đó an ninh là rất quan trọng. Một trong những ý tưởng mà ai đó đã có là buộc người dùng thay đổi mật khẩu cứ sau 3 tháng. Tôi cho rằng điều này là trong khi nó an toàn hơn vì mật khẩu thay đổi thường xuyên, nó cũng buộc người dùng của chúng tôi phải nhớ thay đổi mật khẩu và làm cho nhiều khả năng họ sẽ ghi lại nó ở đâu đó để giúp ghi nhớ.

Trong cùng một ý tưởng là nó thực sự tốt khi buộc người dùng sử dụng một mật khẩu siêu khó đoán. Buộc họ sử dụng?% &% Và chữ hoa viết thường. Tôi biết khá khó khăn để phát minh ra một mật khẩu như vậy và sau đó ghi nhớ nó.

Sau đó, một lần nữa chúng tôi không muốn bất cứ ai sử dụng 12345.

Vì thế. Có bất kỳ whitepapers về chủ đề này? Thực hành tốt?

Tôi đang nói về một trang web được tạo bằng PHP. MySQL trong một môi trường đèn nếu điều đó thay đổi bất cứ điều gì.

Tôi nghĩ rằng tôi có thể là thiểu số trong vấn đề này (dựa trên kinh nghiệm hạn chế của tôi khi làm việc với các bộ phận CNTT ở trường và nơi làm việc), nhưng tôi nghĩ rằng các chính sách thay đổi mật khẩu bắt buộc, dựa trên thời gian là vô giá trị và tệ nhất là có hại. Mọi người có xu hướng rất xấu trong việc chọn mật khẩu tốt và giữ bí mật. Chính sách hết hạn mật khẩu được thiết kế để giảm thiểu điều này bằng cách giới hạn thời gian bất kỳ một mật khẩu nào có thể bị bẻ khóa / thiết kế xã hội / đánh cắp; tuy nhiên, họ không đạt được điều này trong thực tế, chủ yếu vì họ buộc người dùng phải học lại mật khẩu của họ một cách liên tục. Bằng cách khiến người dùng khó khăn hơn trong việc cam kết mật khẩu của họ vào bộ nhớ, cuối cùng bạn sẽ khiến nhiều người trong số họ chọn mật khẩu yếu hơn và / hoặc viết mật khẩu của họ xuống một nơi nào đó nơi mắt tò mò có thể tìm thấy chúng.

Hơn nữa, khi buộc phải thay đổi mật khẩu một cách thường xuyên, nhiều người dùng sẽ chọn mật khẩu theo một mẫu rất dễ nhận biết, chẳng hạn như [base string][digit]. Giả sử người dùng muốn sử dụng tên mèo của họ Fluffy làm mật khẩu. Họ có thể bắt đầu với một mật khẩu fluffy, sau đó thay đổi nó để fluffy1, fluffy2, fluffy3và vân vân. Trong trường hợp này, chính sách không thực sự giúp bảo mật; ngay cả khi người dùng chọn một chuỗi cơ sở an toàn hơn so với fluffyvà ngay cả khi họ giữ mật khẩu của họ được ghi nhớ một cách an toàn, ký tự hậu tố duy nhất thay đổi vài tháng một lần sẽ rất ít để giảm thiểu các cuộc tấn công kỹ thuật xã hội.

Xem thêm: Hết hạn sử dụng mật khẩu được coi là có hại , một bài viết ngắn (không phải do tôi viết) mà tôi nghĩ sẽ giới thiệu tốt về những vấn đề này.

Tổ chức lớn của tôi (hơn 15000 người dùng) đã triển khai "thay đổi mật khẩu" cứ sau 120 ngày vào mùa thu năm 2009. Đó là một vấn đề lớn về CNTT và lãng phí tài nguyên hỗ trợ. Mỗi lần cửa sổ 120 ngày xuất hiện, chúng tôi có hàng ngàn người dùng buộc phải thay đổi mật khẩu .... nhiều người trong số họ làm sai và khóa tài khoản của họ .... hoặc quên vào ngày hôm sau. Bộ phận trợ giúp của chúng tôi bị ngập trong các cuộc gọi mật khẩu mặc dù chúng tôi đã cố gắng tự thực hiện càng nhiều càng tốt.

Nếu bạn muốn người dùng / khách hàng của bạn ghét bạn .... và nhân viên IT tuyến đầu của bạn sẽ đốt cháy bạn trong mọi cơ hội họ nhận được ... thực hiện thay đổi mật khẩu.

Chính sách thay đổi mật khẩu là một hộp kiểm trong một số Trình quản lý CNTT để đặt chỗ ở đâu đó ... và nó đã được viết cách đây 15 năm. Không ai trong các chiến hào thực sự thực hiện hoặc hỗ trợ chính sách sẽ không bao giờ nói với bạn rằng đó là một ý tưởng tốt.

Tôi đã tranh luận ở đây về "vượt qua cụm từ" thay vì mật khẩu .... rất nhiều điều tốt đẹp đã làm ... ánh sáng đó ở cuối đường hầm là một chuyến tàu sắp tới. :)

Một cụm từ là một chuỗi dài gần như không thể đoán được, rất dễ nhớ như "MyCatIsFromSpainAndICallHimElGato". Hoặc có thể là một dòng từ một bài thơ hoặc bài hát.

Nếu bạn muốn làm cho nó thực sự khó bẻ khóa .... gây rắc rối với vụ án, hãy thêm một số dấu câu, thay đổi một số thành ells, ohs thành số không, a thành @, v.v ... Nhưng hãy nhớ nó ... Đó là chìa khóa. Thậm chí còn có cách để chọn chúng để chúng chảy dễ dàng từ ngón tay của bạn đến bàn phím .... vì vậy bạn không bị nảy ra giữa hai bàn tay hoặc với SHIFT và các dấu chấm lạ.

Vì thế...

• Sử dụng "cụm từ vượt qua" dài.
• Kiểm tra chúng trong nội bộ cho sức mạnh.
• Triển khai "đăng nhập một lần" trên toàn bộ cơ sở hạ tầng của bạn để khách hàng chỉ phải sử dụng một hoặc hai lần một ngày.
• Không bao giờ buộc họ phải thay đổi nó.
• Và giáo dục, giáo dục, giáo dục về cách sử dụng đúng đắn của họ.

Matt

EDIT: 24/8/2011 XKCD đồng ý và nói điều đó tốt hơn tôi đã làm.

Không. Ý kiến ​​cá nhân của tôi là nó không cần thiết và thậm chí phản tác dụng . Tôi đã ca ngợi trên blog của mình, nhưng bạn có thể săn lùng nó nếu bạn quan tâm.

Nói tóm lại, có hai lý do:

1. Buộc người dùng liên tục thay đổi mật khẩu dẫn đến mật khẩu xấu.

Sẽ không thiếu bằng chứng giai thoại về điều này, nhưng điều hợp lý là nếu tôi buộc phải nhớ một điều mới mỗi x ngày, tôi sẽ làm cho những điều đó dễ nhớ và có thể liên quan đến nhau.

Người dùng có nhiều khả năng chọn mật khẩu "có thể đoán được" như "Jan2010" hoặc "Password05" nếu họ biết rằng nó sẽ phải thay đổi sớm. Việc thực thi một chính sách nghiêm ngặt đối với các ký tự có thể chỉ dẫn đến một dấu chấm than được thêm vào hoặc một tên được đánh vần đầy đủ thay vì viết tắt. Có một sự khác biệt lớn giữa mật khẩu phức tạp về mặt kỹ thuật và mật khẩu không thể đoán được.

2. Buộc thay đổi mật khẩu thường xuyên không ngăn chặn các cuộc tấn công, nó chỉ làm giảm rủi ro (và không nhiều)

Hãy suy nghĩ về nó - nếu mật khẩu của bạn được đoán hoặc được phát hiện bằng cách nào đó, kẻ tấn công sẽ mất bao lâu để sử dụng thông tin đó? Đặt mình vào vị trí của kẻ tấn công. Bạn vừa phát hiện ra một mật khẩu. Bạn sẽ không đăng nhập và trích xuất từng bit thông tin mà bạn có thể ngay lập tức trong trường hợp ai đó phát hiện ra? Trong 30 ngày, bạn đã có mọi thứ bạn muốn.

Đề nghị của tôi:

• Buộc chính sách mật khẩu cực kỳ nghiêm ngặt (như 15 ký tự có chữ trên, số dưới, số và ký tự đặc biệt, không có từ tiếng Anh> 3 ký tự)
• Không bao giờ làm cho người dùng thay đổi mật khẩu của họ. Nếu họ phải viết mật khẩu trên một tờ giấy và giữ nó trong ví của họ, điều đó thực sự tốt. Mọi người rất giỏi trong việc đảm bảo các mẩu giấy, nhưng không giỏi trong việc ghi nhớ các chuỗi ký tự ngẫu nhiên.

Theo quan điểm của người dùng, việc phải thay đổi mật khẩu của tôi là vô cùng bất tiện. Tôi hoàn toàn ghét phải làm như vậy và sẽ chỉ sử dụng các trang web mà tôi hoàn toàn cần nếu họ yêu cầu tôi thay đổi mật khẩu.

Cũng đã có một số cuộc thảo luận về việc liệu đây có thực sự là một thực hành tốt hay không, vì một số người cuối cùng phải ghi lại mật khẩu của họ để ghi nhớ chúng.

Bạn có thể triển khai một trong những vật dụng đó cho mọi người thấy mật khẩu của họ mạnh (hoặc yếu) như thế nào trong khi họ điền nó vào - Tôi thấy chúng là hữu ích, mặc dù tôi không biết liệu chúng có thực sự mang lại kết quả mạnh hơn không mật khẩu.

Là một người sử dụng môi trường chính sách mật khẩu khá nghiêm ngặt ("siêu khó đoán mật khẩu" và thay đổi mật khẩu giống nhau), ý kiến ​​của tôi là chỉ cần mật khẩu cứng. Mặc dù sẽ mất một chút để người dùng của bạn quen với nó (đặc biệt nếu họ là loại người dùng 12345), họ sẽ có thể nhớ lại và nhập nó dễ dàng trong vòng một tuần.

Tuy nhiên, tôi có thể dự đoán người dùng cuối khó chịu nếu bạn có mật khẩu mạnh như vậy VÀ buộc họ phải thay đổi.

Từ quan điểm quản trị CNTT, tùy chọn tốt nhất của bạn là điều tra khả năng cho phép ứng dụng của bạn sử dụng các khả năng đăng nhập một lần của sơ đồ xác thực hiện có mà khách hàng của bạn đang sử dụng. Rõ ràng Active Directory là một người chơi lớn, nhưng nếu ứng dụng của bạn hoạt động với chính sách CNTT tại chỗ đã được định cấu hình, bạn không phải lo lắng về việc phát minh lại bánh xe.

Vì có quá nhiều cuộc tranh luận về việc thay đổi mật khẩu có được thực thi hay không là một ý tưởng hay (mặc dù tôi nghĩ đó là thứ yếu đối với câu hỏi chính của bạn), tôi nghĩ bạn có thể thích một số ý tưởng & liên kết ở đây . Trong hầu hết các tình huống, nếu bạn không thực thi lịch trình thay đổi mật khẩu phức tạp, bạn cũng có thể không có mật khẩu - nhưng cách nó được thực hiện (đào tạo, hỗ trợ quản lý, v.v.) quan trọng hơn tôi có thể nhấn mạnh.

Thay đổi mật khẩu thường có thể dẫn đến việc người dùng viết chúng xuống. Đó không phải là một ý tưởng tồi như vậy theo Bruce Schneier ( http://www.schneier.com/blog/archives/2005/06/write_down_your.html ).

Tôi thậm chí sẽ lập luận rằng việc bảo mật có được theo cách có thể sử dụng đôi khi có thể là một điều tốt, chỉ vì nó nhắc nhở người dùng hành động an toàn. Ví dụ, trong ngân hàng nơi tôi làm việc, rất nhiều biện pháp an ninh được áp dụng là nhà hát an ninh (ví dụ: nhận dạng khuôn mặt ở cửa, nhưng anh chàng bảo vệ sẽ mở cửa cho bạn nếu việc nhận dạng thất bại). Mặc dù các biện pháp đó không tự cải thiện an ninh, nhưng chúng luôn có mặt để nhắc nhở chúng tôi rằng bảo mật là một mối quan tâm quan trọng trong công việc, rằng có một số lượng đăng nhập và kiểm tra đang diễn ra, và nếu bạn bị bắt làm gì đó "không an toàn" sẽ gặp rắc rối

Tất nhiên, điều này áp dụng cho bảo mật cho nhân viên của một ngân hàng, nó có thể không áp dụng cho người dùng trang web của bạn ...

Bạn nên buộc người dùng thay đổi mỗi n ngày nếu chính sách bảo mật của bạn yêu cầu. Tôi làm việc cho một cơ quan Nhà nước và đây là một yêu cầu được thi hành từ văn phòng của Kiểm toán Nhà nước. Tôi không thể làm gì với nó, vì vậy tôi phải buộc thay đổi.

Nếu bạn không bị ràng buộc bởi quy định để buộc thay đổi mật khẩu, đừng ép buộc họ. Đảm bảo rằng các mật khẩu được thiết lập đáp ứng các yêu cầu phức tạp tối thiểu nhất định. Độ dài vượt quá độ phức tạp đối với hầu hết các hệ thống mật khẩu, do đó, theo tôi, một tiêu chuẩn biến đổi là trường hợp tốt nhất. Nhu la:

• Không có mật khẩu sẽ ít hơn 10 ký tự.
• Mật khẩu từ 10-25 ký tự sẽ cần ít nhất 3 bộ ký tự.
• Mật khẩu từ 25 đến 40 ký tự sẽ cần ít nhất 2 bộ ký tự.
• Mật khẩu dài hơn 40 ký tự có thể sử dụng một bộ ký tự.

Các lược đồ phức tạp tích hợp sẵn cho những thứ như Active Directory không hỗ trợ loại hệ thống tầng này. Nếu bạn xây dựng môi trường thay đổi mật khẩu của riêng bạn, bạn có thể làm những thứ như thế này. Bởi vì mỗi lần sử dụng phím shift làm tăng khả năng xảy ra sự kiện ngón tay mập, mật khẩu dài với nhiều bộ ký tự có nhiều khả năng phát sinh các sự kiện đăng nhập thất bại, đặc biệt là trong giai đoạn học tập. Nếu bạn có một hệ thống khóa tài khoản tại chỗ, đây có thể là một vấn đề lớn. Đối với người sử dụng dòng thứ 3 của bài thơ yêu thích của họ (63 ký tự!) Làm cụm từ mật khẩu của họ, không phải h @ x0r, nó giúp việc nhập nhanh và hiệu quả.

Nếu công nghệ hoặc môi trường rủi ro thay đổi đáng kể và mật khẩu của bạn bây giờ không phức tạp như mong muốn, hãy đặt một cách để hết hạn mật khẩu trong một khoảng thời gian. Mọi người sẽ càu nhàu về sự cần thiết, đặc biệt là nếu bạn chưa bao giờ bắt buộc thay đổi trước đây, nhưng nó sẽ giúp bạn duy trì tư thế bảo mật.

Khó đoán mật khẩu là một điều tốt. Thực thi các mức độ phức tạp dẫn đến việc người dùng quên mật khẩu hoặc phải ghi lại chúng là một điều tồi tệ, bởi vì bất kỳ bảo mật nào đạt được bởi sự phức tạp đều bị mất hoàn toàn trong quy trình. Trong một thế giới lý tưởng (không may là không phải nơi chúng ta sống) cần có sự đánh đổi cân bằng giữa sự phức tạp và khả năng sử dụng. Tất nhiên những người khác nhau sẽ thấy điểm cân bằng ở những nơi khác nhau.

Logic đằng sau việc thay đổi mật khẩu thường xuyên trong X ngày là một chút mất đối với tôi. Lý do tôi thường nghe cho điều này là để hạn chế tính hữu ích của mật khẩu bị đánh cắp, mà tôi trả lời rằng mọi thiệt hại thực sự gần như chắc chắn sẽ được thực hiện trong vài giờ đầu tiên. ví dụ Fred "làm quen với" mật khẩu của Mary. Trừ khi điều đó xảy ra gần như cùng lúc với việc Mary đang thay đổi mật khẩu đó, thì điều đó có gì khác biệt nếu nó thay đổi vào ngày mai hoặc tháng tới? Có thực sự có khả năng Fred sẽ đợi một hoặc hai tuần nữa trước khi sử dụng mật khẩu (giả sử đó là ý định hoàn toàn không)?

Rõ ràng thay đổi mật khẩu nếu có bất kỳ lý do hoặc nghi ngờ rằng nó có thể cần thiết là một vấn đề hoàn toàn khác.

Nếu ứng dụng cần mức bảo mật cao như vậy, bạn đã cân nhắc sử dụng thứ gì đó như mã thông báo SecurID chưa? Điều này có nghĩa là người dùng sẽ nhận được mật khẩu mới cứ sau 60 giây; bạn không phải lo lắng về việc họ sử dụng viết mật khẩu. Tuy nhiên, những điều này làm tốn tiền. Làm thế nào an toàn để giải pháp phải được?

Tôi nghĩ rằng thông tin cho người dùng là quan trọng. Giải thích cho họ cách tạo mật khẩu và tầm quan trọng của việc không sử dụng cùng một mật khẩu hai lần. Một cách dễ dàng để tạo mật khẩu là lấy một câu và lấy chữ cái đầu tiên trong mỗi từ và thêm một số số.

Vd Tôi thích thống trị thế giới = Iltrw99

Đừng buộc họ thay đổi mật khẩu, nó sẽ chỉ khiến họ bối rối.

Mặc dù tôi không đồng ý với việc thay đổi mật khẩu ba tháng một lần, đây là một yêu cầu nếu công ty của bạn được giao dịch công khai và đó là một phần của việc tuân thủ SOX. Lưu ý bên: Sarbanes-Oxley hút.

Một cái gì đó tôi không thấy đề cập đến là truy cập bên ngoài vào tài nguyên.

Tôi có xu hướng đồng ý rằng nếu bạn chọn một chính sách mật khẩu hợp lý, trừ khi ai đó viết nó xuống, không ai có thể đoán được mật khẩu đó.

Tuy nhiên, giả sử bạn có thể truy cập webmail ngoại vi, bây giờ bạn có khả năng người dùng nhập thông tin đăng nhập của họ vào "bất kỳ PC cũ" nào và IMO làm tăng rủi ro cho dữ liệu doanh nghiệp của bạn do phần mềm gián điệp / phần mềm độc hại / trojan gây ra và do đó có thể đánh hơi / đánh cắp các mật khẩu đó .

Nếu mọi người viết ra mật khẩu đơn giản, điều gì khiến bạn nghĩ rằng họ sẽ không viết ra một mật khẩu lớn hoặc mật khẩu siêu phức tạp. Những thay đổi mật khẩu gia tăng thực hiện là việc thanh lọc ID người dùng không còn được sử dụng tự động nữa và nó cho phép người dùng cá nhân có một số trách nhiệm trong tất cả những điều này. Mọi người sẽ trở thành người, tìm kiếm con đường dễ dàng để hoàn thành một cái gì đó; mật khẩu lặp lại và mật khẩu thay đổi tăng dần có thể được phát hiện và từ chối. Các yêu cầu phức tạp có thể được đưa vào, thay đổi mật khẩu bắt buộc cũng có thể mở mắt cho những người dùng không phải CNTT để chịu trách nhiệm cao hơn trong tất cả những điều này. Hầu hết những người dùng phàn nàn về việc thay đổi mật khẩu là những người lười biếng giả vờ thay đổi mật khẩu của họ giống như phẫu thuật tim hở. Dừng than vãn, có trách nhiệm và ngừng cố gắng tìm đường dễ dàng,