Tôi đã tìm thấy trong một số trường hợp, việc buộc người dùng thay đổi mật khẩu một cách thường xuyên sẽ trở nên khó khăn hơn trong việc bảo trì hơn là giúp bảo mật. Ngoài ra, tôi đã thấy người dùng viết mật khẩu mới của họ xuống vì họ không có đủ thời gian để nhớ mật khẩu của mình và không thể bận tâm học lại mật khẩu khác.
Lợi ích bảo mật nào là có để buộc thay đổi mật khẩu?
Câu trả lời:
Đây là một cách khác với nhật ký Sans:
Quy tắc mật khẩu: Thay đổi chúng sau mỗi 25 năm
Có một lợi ích thiết thực. Nếu ai đó có mật khẩu của bạn và tất cả những gì họ muốn là đọc email của bạn và không bị phát hiện, họ có thể làm như vậy mãi mãi, trừ khi cuối cùng bạn thay đổi bí mật đăng nhập. Do đó, việc thường xuyên thay đổi mật khẩu không giúp ích nhiều cho việc ai đó xâm nhập và làm mất mật khẩu với hàng hóa của bạn, nhưng nó KHÔNG cho bạn cơ hội rũ bỏ bất kỳ kẻ rình rập hoặc kẻ rình mò nào bạn có thể truy cập vào tài khoản của mình. Vâng cái này rất tốt. Nhưng liệu lợi ích này có đáng để phiền phức và đề cập đến những bất lợi của việc buộc người dùng thay đổi mật khẩu của họ sau mỗi 90 ngày hay không, tôi vẫn nghi ngờ.
Buộc thay đổi mật khẩu khi bạn đoán nó (bằng cách chạy chương trình đoán mật khẩu trên tất cả người dùng của bạn mọi lúc).
Thật khó để tranh luận với "bạn phải thay đổi mật khẩu" khi câu trả lời là "tại sao?" là "bởi vì chúng tôi đã có thể đoán nó bị mù". Nó tự động thưởng cho những người chọn mật khẩu khó đoán và dạy cho người dùng của bạn biết mật khẩu nào yếu. Nếu họ chọn "password1", nó sẽ hết hạn trước khi họ có thể đăng nhập một lần. Nếu người dùng chọn mật khẩu 16 ký tự, ngẫu nhiên, hỗn hợp, chữ và số, bạn sẽ không bao giờ đoán được - và cũng không phải ai khác. Chúng ta hãy giữ nó trong một thời gian rất dài và thậm chí họ sẽ có thể ghi nhớ nó.
Đó là một sự đánh đổi. Yêu cầu thay đổi mật khẩu thường xuyên sẽ dẫn đến mật khẩu chất lượng thấp hơn. Thậm chí đã có nghiên cứu về hiệu ứng này.
Điều đó đang được nói, cách đáng tin cậy duy nhất tôi đã tìm thấy để ngăn người dùng chia sẻ mật khẩu là yêu cầu thay đổi mật khẩu định kỳ. Kinh nghiệm của tôi cho thấy 90 ngày dường như là một sự thỏa hiệp hợp lý giữa khả năng sử dụng và bảo mật. Nếu bạn đi lâu hơn, mọi người bắt đầu dựa vào mật khẩu được chia sẻ - sớm hơn và bạn kết thúc với "tháng 1109", "tháng 12 năm09".
Điều tồi tệ nhất về việc buộc thay đổi mật khẩu không phải là bạn thực sự khiến mọi người thay đổi mật khẩu. Thông thường nó đi kèm với rất ít hoặc không có cảnh báo, và họ ngay lập tức gặp phải một vấn đề cần giải quyết ngay lập tức, vì vậy thay vì cho ai đó thời gian để nghĩ ra một mật khẩu tốt, nhiều khả năng đó là một mật khẩu kém an toàn hơn nhưng dễ nhớ hơn, hoặc an toàn hơn nhưng nó chỉ được viết ra, do đó phủ nhận lợi thế bảo mật.
Nếu mật khẩu đủ phức tạp mà chúng không dễ đoán và chúng không được chia sẻ giữa các hệ thống và không chắc là nó đã bị xâm phạm, thì việc thay đổi mật khẩu có lẽ không quan trọng lắm.
Tuy nhiên, nếu bất kỳ điều nào xảy ra, và hai cái đầu tiên có lẽ phổ biến hơn không, buộc mọi người phải thay đổi mật khẩu định kỳ có nghĩa là ít nhất họ sẽ ít chia sẻ mật khẩu.
Điều đó nói rằng, tôi sẽ chọn cách giáo dục người dùng của bạn về ý nghĩa của một mật khẩu tốt và tại sao việc chia sẻ chúng lại rất tệ. Viết chúng xuống là phổ biến cho dù bạn làm gì.
Tôi khuyên mọi người nên chọn mật khẩu từ một cuốn sách mà họ biết, bằng cách nhớ một số trích dẫn không quen thuộc từ nó hoặc tạo thành một cụm từ. Sử dụng chữ cái đầu tiên từ mỗi từ và thêm hai số bên trong đó ở đâu đó. Hầu hết mọi người có thể nhớ rằng sau khi họ đã gõ nó một vài lần.
Tôi thấy không có lợi ích trong thực hành đó cả.
Mật khẩu mạnh là quan trọng hơn nhiều. Theo ý nghĩa mạnh mẽ, tôi có nghĩa là 9+ chữ số + ký hiệu đặc biệt hoặc mật khẩu / cụm từ không phải từ điển 15+ [az] (điều này dựa trên một nghiên cứu gần đây về chi phí của mật khẩu bruteforcing sử dụng EC2 của Amazon).
Các hệ thống truy cập từ xa phải có phần mềm phát hiện và ngăn chặn bruteforce (ví dụ fail2ban) trên tất cả các dịch vụ tiếp xúc. Điều này quan trọng hơn nhiều, IMO, so với chính sách thay đổi mật khẩu thông thường.
Vấn đề cơ bản là mật khẩu, như một cơ chế bảo mật, bốc mùi.
Nếu bạn yêu cầu mọi người thay đổi chúng thường xuyên, họ sẽ viết chúng ra. Nếu bạn yêu cầu họ sử dụng 30 mật khẩu chữ cái với ít nhất 3 số, 4 chữ cái viết hoa và ký tự điều khiển, họ sẽ quên chúng hoặc viết chúng xuống hoặc làm những việc ngớ ngẩn khác. Nếu chúng đơn giản, người dùng sẽ sử dụng mật khẩu ngu ngốc như bunny7 hoặc Bunny7. Và họ sẽ sử dụng cùng một mật khẩu xấu cho mọi thứ, bao gồm cả tài khoản khiêu dâm và tài khoản hotmail của họ.
Tôi thích các công cụ như Mobile OTP , cho phép người dùng sử dụng điện thoại di động của họ như một công cụ xác thực hai yếu tố.
Về lâu dài, có khả năng chúng ta sẽ bằng cách nào đó hạ cánh xuống một thế giới với các certs được mã hóa làm cơ chế nhận dạng người dùng. Những thứ như OpenID và CAS đơn giản hóa xác thực người dùng và cho phép đăng nhập một lần thuận tiện.
Về lâu dài, cách tốt nhất là giảm số lần người dùng cần cấp thông tin đăng nhập - loại bỏ mật khẩu "HR" và mật khẩu "bảng chấm công" và mật khẩu "CRM". Hợp nhất chúng thành một cơ sở hạ tầng xác thực chung yêu cầu người dùng cấp thông tin đăng nhập của họ một lần. Sau đó, họ sử dụng một cái gì đó như MobileOTP hoặc RSA SecurID sử dụng xác thực hai yếu tố.
Trong ngắn hạn, các chính sách mật khẩu sẽ là chủ đề của các cuộc chiến tôn giáo. Chỉ cần làm bất cứ điều gì sếp yêu cầu bạn, và nếu bạn là sếp, hãy sử dụng phán đoán của bạn dựa trên hồ sơ bảo mật cơ sở người dùng và dự kiến của bạn.
Chúc may mắn!
Cách làm này, không hoàn toàn vô dụng, từ lâu đã quan trọng hơn nhiều. Tranh luận về chính sách này thực sự phản tác dụng, vì nó chuyển hướng sự chú ý khỏi các mối đe dọa hiện tại nghiêm trọng hơn nhiều.
Xem xét:
Nếu bạn sử dụng Windows / AD và tài khoản không có hộp kiểm tra "Tài khoản nhạy cảm và không thể được ủy quyền", tài khoản đó có thể được sử dụng thông qua mạo danh và không cần mật khẩu. Mã để làm điều này là tầm thường.
Nếu máy trạm windows của một người bị xâm phạm từ lỗ hổng bảo mật, mã thông báo bảo mật trong bộ nhớ trong của họ có thể được sử dụng để truy cập vào các máy tính khác. Một lần nữa, không cần mật khẩu.
Nhân tiện, thứ hai, đó là lý do tại sao bạn chỉ nên truy cập các máy chủ sử dụng tài khoản khác với tài khoản người dùng thông thường hàng ngày của bạn. Cũng lưu ý rằng cả hai kịch bản đều đánh bại hoàn toàn ngay cả các cơ chế xác thực hai yếu tố mạnh mẽ nhất.
Điều tốt nhất có thể xảy ra liên quan đến bảo mật mật khẩu là ngừng tranh luận về nó và tập trung vào các mối đe dọa hiện đại và nghiêm trọng hơn.
Thêm thông tin:
Hãy xem bài thuyết trình của Luke Jennings, "Một mã thông báo để thống trị tất cả":
http://eusecwest.com/esw08/esw08-jennings.pdf
Insomnia Shell - ví dụ về mã được yêu cầu để thỏa hiệp mã thông báo trên máy chủ ASP.Net:
http://www.insomniasec.com/release/tools
Cách thực hiện: Sử dụng chuyển đổi giao thức và ủy quyền ràng buộc trong ASP.NET 2.0
http://msdn.microsoft.com/en-us/l Library / ms998355.aspx
Tìm kiếm "không có mật khẩu".
Mật khẩu càng dài không thay đổi thì càng có nhiều khả năng bị xâm phạm, đơn giản vì sẽ có nhiều cơ hội hơn cho các tình huống có thể bị xâm phạm (trong một khoảng thời gian vô hạn mọi thứ đều có thể). Nó cũng làm cho nó khó thay đổi hơn trong tương lai vì người dùng sẽ quen với cái cũ. Một rủi ro nữa là nếu nó bị xâm phạm và người dùng không biết thực tế có khả năng xảy ra một số hành vi lạm dụng nghiêm trọng tài khoản của người dùng. Các thay đổi định kỳ ít nhất sẽ giảm thiểu rằng khi thay đổi mật khẩu được thi hành tiếp theo sẽ khiến mật khẩu bị xâm phạm trở nên vô dụng.
Theo kinh nghiệm của tôi, kịch bản rất có thể khiến người dùng viết mật khẩu là thiếu suy nghĩ liên kết trong cơ sở hạ tầng bảo mật của bạn, chẳng hạn như có nhiều hệ thống khác nhau, tất cả đều yêu cầu kết hợp tên người dùng và mật khẩu riêng. Ném 5 trong số đó vào một người dùng và bạn sẽ nhận được hội chứng ghi chú màu vàng với sự báo thù.
Chính sách mật khẩu hợp lý cho phép người dùng chọn mật khẩu dễ nhớ nhưng khó bẻ khóa, cùng với một số giáo dục người dùng tốt, một số xác thực tích hợp vững chắc, và các chính sách hết hạn và hết hạn, tất cả đều được hỗ trợ bởi AUP, rõ ràng cấm chia sẻ mật khẩu, là cách tốt nhất.
Nếu bạn đang lưu trữ thông tin đăng nhập (mà hầu hết mọi người làm cho tính khả dụng) thì đây là điều bắt buộc. Nếu một máy tính bị đánh cắp vật lý và bộ nhớ đệm thông tin được kích hoạt, thì kẻ trộm có thể buộc máy tính rời khỏi mạng mà không sợ chính sách khóa tài khoản được kích hoạt. Sau đó, họ có thông tin hợp lệ cho tài nguyên mạng của bạn. Thay đổi các mật khẩu theo định kỳ có thể giúp giảm thiểu thiệt hại này.
Đây là lý do chính xác mà bạn không bao giờ đăng nhập bằng tài khoản đặc quyền, bạn luôn đăng nhập với tư cách là người dùng hạn chế và nâng cao lời nhắc cá nhân, điều này ngăn thông tin đăng nhập đặc quyền khỏi bị ép buộc trong trường hợp trộm cắp / đột nhập.
Tôi đang ở trong trại không bao giờ yêu cầu thay đổi mật khẩu. Hoặc như bài báo nói - cứ sau 25 năm - vâng tôi sẽ chết sau đó. Tốt Đây là lý do tại sao ... tôi có 12 mật khẩu cần nhớ trong công việc của mình. Hầu hết trong số họ thay đổi và những người thay đổi là trên lịch trình hoàn toàn khác nhau. Họ đều có yêu cầu sức mạnh khác nhau. Làm thế nào một con người yếu đuối có thể đối phó với điều này? Một số cách tôi đã thấy: Viết chúng lên bảng trắng. Viết chúng trên một tờ giấy và giữ chúng trong một ngăn kéo không khóa. hoặc phương pháp ưa thích của tôi: lưu trữ chúng trong bảng tính google doc khá không an toàn. Không có cách nào bạn có thể thuyết phục tôi rằng bất kỳ phương pháp nào trong số này (RẤT phổ biến) không hoàn toàn bù đắp bất kỳ lợi ích bảo mật nhỏ nào có được bằng cách yêu cầu thay đổi.
Tôi có thời gian để viết bài này vì tôi đang chờ ai đó hỗ trợ CNTT để mở khóa một trong những tài khoản của mình. Rõ ràng lần trước tôi đã không cập nhật bảng tính của mình. Có một nghiên cứu tính toán BILLION $$$ bị mất cho điều vô nghĩa này?