Vừa nhận được email từ một nhà cung cấp thông báo cho chúng tôi rằng họ sẽ buộc chúng tôi thay đổi mật khẩu sáu tháng một lần, tôi tò mò muốn xem chính sách hết hạn mật khẩu mà mọi người sử dụng và lý do họ sử dụng chúng.
Câu trả lời:
Có một ranh giới tốt ở đây giữa việc không bao giờ thay đổi nó và thay đổi nó quá thường xuyên. Có cùng một mật khẩu trong nhiều năm thường không phải là một giải pháp tốt, đặc biệt là nếu nó có sẵn công khai. Nhưng việc buộc một chính sách cứng nhắc thay đổi nó quá thường xuyên cũng có tác dụng phụ xấu. Một nơi tôi làm việc, buộc tất cả người dùng trên mạng nội bộ phải thay đổi mật khẩu mỗi tuần thứ 6 và mật khẩu không thể giống như sáu mật khẩu trước đó. Ba mật khẩu sai đã khóa máy trạm và nhân viên IT phải mở khóa. Điều đó dẫn đến việc mọi người viết mật khẩu trên các ghi chú Post-It treo trên màn hình hoặc đặt trong ngăn kéo của họ. Ác mộng.
Tôi muốn nói thay đổi mật khẩu 6 tháng một lần là đủ. Điều này sẽ tránh những ghi chú Post-It đáng sợ.
Tôi sẽ đề nghị sử dụng một chút toán học có tính đến độ phức tạp mật khẩu tối thiểu của bạn, kẻ tấn công có thể đoán mật khẩu nhanh như thế nào, số tài khoản đã mở khóa mà bạn có và một số thông tin được thông báo về rủi ro của bạn.
Hy vọng rằng bạn có một số loại giới hạn tỷ lệ để đoán mật khẩu. Thông thường, đó sẽ là thông qua một cái gì đó tạm thời khóa tài khoản sau một số mật khẩu xấu.
Và hy vọng bạn có một số loại yêu cầu về độ phức tạp của mật khẩu để "A" và "mật khẩu" không được phép.
Giả sử sau 30 lần thất bại mật khẩu trong 10 phút, bạn sẽ khóa tài khoản trong 20 phút. Điều đó có hiệu quả giới hạn tỷ lệ đoán mật khẩu ở mức 174 mỗi giờ, hoặc 4176 mỗi ngày. Nhưng hãy giả sử nó cho mỗi người dùng.
Giả sử bạn yêu cầu 8+ mật khẩu ký tự chứa các số trên, dưới và một số, và bạn thực hiện một số kiểm tra từ điển để đảm bảo rằng các mật khẩu đó là ngẫu nhiên hợp lý. Trường hợp xấu nhất là tất cả người dùng của bạn đều đặt một số trên và một số ở cùng một vị trí và kẻ tấn công của bạn biết điều đó, vì vậy bạn đã có mật khẩu 10 * 26 ^ 7 (80G). Trường hợp tốt nhất là 62 ^ 8 (218T).
Vì vậy, kẻ tấn công thử mọi mật khẩu có thể sẽ tấn công tất cả chúng trong vòng 50.000 năm trong trường hợp xấu nhất và gần 600 triệu milimet trong trường hợp tốt nhất. Hoặc, nói cách khác, trong một năm họ sẽ có từ 1 trên 50.000 đến 1 trong 52.000.000.000 lượt đoán. Nếu bạn có số lượng người dùng 50.000, gần như đảm bảo rằng trong trường hợp xấu nhất họ sẽ vào một tài khoản mỗi năm và có khoảng 50% cơ hội nhận được một tài khoản mỗi 6 tháng.
Và nếu bạn không có giới hạn tỷ lệ và kẻ tấn công có thể đoán được một tỷ mật khẩu mỗi ngày? Một trong 600 cơ hội nhận được tài khoản trong một năm hoặc đảm bảo ảo nhận được khoảng 80 trong số 50.000 người dùng của bạn mỗi năm.
Làm việc trên toán học đó và tìm ra mức độ rủi ro chấp nhận được của bạn. Và hãy nhớ rằng bạn đặt nó càng ngắn thì người dùng sẽ càng khó nhớ và càng có nhiều khả năng họ sẽ viết nó xuống một nơi nào đó thuận tiện cho kẻ tấn công tại chỗ.
Như một phần thưởng bổ sung: nếu ai đó đang thử hàng ngàn mật khẩu mỗi người dùng mỗi ngày đối với các hệ thống của bạn, tôi thực sự hy vọng bạn có một số loại giám sát sẽ chọn ra điều đó.
EDIT: Quên đề cập đến: chính sách thực tế của chúng tôi là 90 ngày, nhưng điều đó có liên quan đến những phát hiện của các kiểm toán viên an ninh sai lầm và không liên quan gì đến thực tế.
90 ngày dường như là đủ cho hầu hết các kịch bản. Mối quan tâm lớn nhất của tôi là sự phức tạp của mật khẩu. Nhiều hơn vấn đề khung thời gian trong việc tạo ghi chú sau đó là sự phức tạp bắt buộc. Đó là một điều để tránh các từ trong từ điển và một từ khác để có các ký tự đặc biệt, nhưng khi bạn bắt đầu nói rằng không có ký tự nào có thể lặp lại hoặc theo thứ tự tăng dần / giảm dần, bạn đã làm cho người dùng của bạn gặp khó khăn. Thêm vào đó là một cuộc sống mật khẩu ngắn và bạn vừa được chào đón trong nhiều vấn đề hơn.
Mật khẩu hết hạn gây phiền nhiễu và giảm bảo mật.
Mật khẩu hết hạn bảo vệ chống lại tình huống kẻ tấn công đã xâm phạm mật khẩu của người dùng một lần, nhưng không có cơ chế tìm hiểu nó là gì trên cơ sở đang diễn ra (ví dụ: keylogger)
Tuy nhiên, nó cũng khiến việc nhớ mật khẩu trở nên khó khăn hơn, khiến nhiều khả năng người dùng sẽ ghi lại chúng.
Vì việc bảo vệ chống lại mật khẩu đã bị xâm phạm là không thực sự cần thiết (bạn hy vọng), tôi coi việc hết hạn mật khẩu là vô ích.
Yêu cầu người dùng chọn một mật khẩu mạnh để bắt đầu; khuyến khích họ ghi nhớ nó, sau đó không yêu cầu họ thay đổi nó, bao giờ, hoặc cuối cùng họ sẽ viết chúng xuống mọi nơi.
Nếu bạn có một thiết bị cần bảo đảm bảo mật "cao đến cực cao", tốt hơn hết bạn nên sử dụng mã thông báo phần cứng tạo mật khẩu một lần thay vì dựa vào việc hết hạn mật khẩu.
"Thắng" chính cho hệ thống hết hạn mật khẩu là bạn SILL, cuối cùng, sẽ bị vô hiệu hóa tài khoản nếu chủ tài khoản rời khỏi tổ chức, vì "vô hiệu hóa" kiểm tra và cân bằng "thành" tài khoản nên bị vô hiệu hóa khi chủ tài khoản bị vô hiệu hóa lá".
Việc thực thi dẫn đến hết hạn mật khẩu, tốt nhất là mật khẩu chất lượng cao được viết ra và trong trường hợp xấu nhất là mật khẩu xấu (tại nơi làm việc trước đây, một khi chúng tôi buộc phải sử dụng hết hạn mật khẩu, cuối cùng tôi đã sử dụng (về cơ bản) prefixJan2003, prefixFeb2003 và trên, như phương pháp tạo mật khẩu ưa thích của tôi (48 bit ngẫu nhiên, được mã hóa Base64) không mở rộng thành "mật khẩu mới mỗi tháng").
Tôi nghĩ rằng nếu bạn hỏi 10 chuyên gia bảo mật khác nhau câu hỏi này - bạn sẽ nhận được 10 câu trả lời khác nhau.
Điều này phụ thuộc rất nhiều vào mức độ quan trọng của tài sản mà mật khẩu đang bảo vệ.
Nếu bạn có một tài sản có độ an toàn cao, bạn cần đặt chính sách hết hạn mật khẩu của mình đủ ngắn để bất kỳ kẻ xâm nhập bên ngoài nào sẽ không có thời gian để bắt bẻ mật khẩu. Một biến khác trong tình huống này là mức độ phức tạp được yêu cầu trên mật khẩu.
Đối với các hệ thống bảo mật thấp đến trung bình tôi nghĩ rằng chính sách hết hạn 6 tháng là rất công bằng.
Đối với bảo mật cấp cao, tôi nghĩ rằng một tháng sẽ tốt hơn - và đối với các cài đặt an toàn 'cực kỳ' thậm chí sẽ có thời gian ngắn hơn.
Chúng tôi thi hành hết hạn mật khẩu 90 ngày đối với mọi người ở đây, (bao gồm cả chính chúng tôi.)
Chủ yếu là vì nó đơn giản là thực hành tốt nhất. Cơ hội của một người nào đó sử dụng mật khẩu "yếu", so với mật khẩu mạnh hơn sẽ càng lớn và bạn càng để lâu thì điều đó sẽ dẫn đến vi phạm bảo mật lâu dài, không bị phát hiện.
Chúng tôi hết hạn mật khẩu hàng năm và yêu cầu mật khẩu mạnh (tốt nhất là ngẫu nhiên) dài hơn 10 ký tự. Chúng tôi chạy các cuộc tấn công từ điển vào mật khẩu của mọi người khi họ thay đổi chúng. Chúng tôi giữ quá khứ băm mật khẩu để mật khẩu không thể được sử dụng lại. Chúng tôi cũng kiểm tra ngày tiềm năng trong mật khẩu như vatine nói. ;) Cuối cùng là sự bổ sung của tôi ...
Tại một công việc trước đây, chúng tôi đã cố gắng hết hạn thường xuyên hơn theo lệnh của quản trị viên an ninh mạng mới - cứ sau hai tháng. Hai tuần sau lần thay đổi bắt buộc đầu tiên, tôi đưa anh ấy đi khắp các văn phòng hành chính của chúng tôi và chúng tôi nhìn vào bàn phím và bàn di chuột của mọi người. Hơn 50% trong số họ có một mật khẩu được viết trên một bài đăng bên dưới. Anh ấy rất vui khi nới lỏng chính sách sau khi chúng tôi ngồi xuống và nói chuyện với nhân viên hành chính - ý kiến của họ là họ không có đủ thời gian để ghi nhớ.
Hầu hết những thứ của chúng tôi ngày nay là đăng nhập một lần trong một vài silo. Tài nguyên tại trường (hiếm khi được sử dụng cho hầu hết mọi người) nằm trong một silo và mật khẩu đó được quản lý bởi nhóm CNTT trung tâm của chúng tôi. Tài nguyên của bộ phận (được sử dụng hàng ngày - đăng nhập máy, email, chỉnh sửa trang web, máy photocopy) là mật khẩu được quản lý bởi nhóm của chúng tôi, cũng đã hết hạn hàng năm. Nếu mọi người hiểu về việc thất vọng, chúng tôi chỉ ra rằng họ thực sự chỉ có một mật khẩu để nhớ.
Ngày nay, tôi tạo một md5sum trên một tệp ngẫu nhiên trong / var / log và sử dụng một tập hợp con cho mật khẩu của mình.
Chúng tôi đã có rất nhiều cuộc thảo luận về điều này một vài năm trước đây khi chúng tôi bắt đầu chính sách hết hạn mật khẩu. Chúng tôi vừa hoàn thành một cuộc chạy l0phcract với các bàn cầu vồng chống lại cây AD để xem nó tệ như thế nào, và nó thật kinh khủng. Một số người dùng bị chảy máu mắt vẫn sử dụng mật khẩu "helpdesk temp" của họ sau khi gọi vào / thả bằng cách đặt lại mật khẩu, một cái gì đó khủng khiếp như 30% đã sử dụng "mật khẩu" hoặc một số biến thể làm mật khẩu của họ (p @ $$ w0rd, v.v.) . Điều đó thuyết phục quản lý rằng điều này cần phải xảy ra.
Là ed cao hơn, chúng tôi đã có mùa hè để tranh đấu khi chọn một khoảng. Rất nhiều giảng viên của chúng tôi không dạy trong mùa hè, vì vậy bộ phận trợ giúp của chúng tôi đã phải chuẩn bị cho các cuộc gọi "Tôi quên mật khẩu" khi tất cả họ quay lại vào tháng Chín. Tôi nghĩ, và tôi có thể sai, rằng khoảng thời gian của chúng tôi là 6 tháng với một ngoại lệ vào quý hè. Vì vậy, nếu hết hạn mật khẩu 6mo của bạn hết hạn vào giữa tháng 8, nó sẽ được lập trình lại ngẫu nhiên để thiết lập lại vào cuối tháng 9 đến đầu tháng 10.
Một câu hỏi tốt hơn là tần suất tài khoản tiện ích và tài khoản quản trị viên của bạn được xoay vòng. Tất cả quá thường xuyên những người dường như được miễn các chính sách thay đổi mật khẩu. Ai muốn thông qua tất cả các tập lệnh để thay đổi mật khẩu tài khoản tiện ích? Và một số hệ thống sao lưu làm cho việc thay đổi mật khẩu đã sử dụng trở nên khó khăn, điều này mang lại sự không phù hợp để thay đổi mật khẩu quản trị viên.
Một vấn đề lớn với việc hết hạn mật khẩu thường xuyên là mọi người sẽ phải vật lộn để nhớ chúng, vì vậy bạn sẽ có người sử dụng mật khẩu yếu hoặc tương tự hoặc nếu chính sách của bạn không cho phép điều này, họ sẽ bắt đầu ghi lại mật khẩu để giúp ghi nhớ chúng . Bạn cũng sẽ có nhiều yêu cầu thay đổi mật khẩu hơn, khi mọi người quên chúng.
Cá nhân, nó phụ thuộc vào mật khẩu được sử dụng để làm gì, nhưng tôi có xu hướng không giữ mật khẩu quá 3 tháng, trừ khi đó là một tài khoản bị vứt bỏ hoàn toàn. Đối với những thứ có rủi ro cao hơn, mỗi tháng hoặc lâu hơn là tốt, và thách thức thay đổi nó nếu người khác biết nó rời đi. Vì tôi làm việc trong một doanh nghiệp hỗ trợ máy tính nhỏ, chúng tôi có nhiều mật khẩu được chia sẻ giữa nhiều người, vì vậy chúng tôi không muốn thay đổi chúng thường xuyên, vì sự gián đoạn có thể gây ra.
Bình luận thú vị cho đến nay. Tất nhiên tại sao luôn luôn tranh luận rằng việc nhớ mật khẩu là vấn đề nhân sự kỹ thuật so với phi kỹ thuật trong một công ty? Khả năng của ai đó với phần cứng / phần mềm máy tính có liên quan gì đến khả năng bảo mật nghiêm trọng của họ? Một người không có kỹ thuật sẽ đưa ra Thẻ tín dụng hoặc Thẻ ghi nợ # của họ? Ngoài ra, những người đặt mật khẩu trên ghi chú sau nó trên bàn của họ nên là căn cứ để sa thải. Thật đáng kinh ngạc khi trí nhớ của mọi người sẽ cải thiện khi họ thực sự nhận ra an ninh là quan trọng và phải được thực hiện nghiêm túc. Tôi thấy không khác gì vai trò của quy tắc ăn mặc và thực hiện các chính sách tại nơi làm việc. Thực hiện theo các quy tắc hoặc tạm biệt!
Tôi nghĩ rằng việc có một mật khẩu an toàn hơn quan trọng hơn nhiều so với việc thường xuyên thay đổi nó, nhưng cả hai đều chắc chắn cần thiết cho một hệ thống an toàn.
Lập luận cho rằng mật khẩu phức tạp rất khó nhớ và dẫn đến nhân viên viết chúng xuống. Tôi tin vào điều này là phần lớn các cuộc tấn công đến từ bên ngoài , và thậm chí viết ra một mật khẩu phức tạp và gõ nó vào màn hình của bạn an toàn hơn là ghi nhớ một mật khẩu đơn giản.
Tôi đang triển khai xác thực dựa trên mã thông báo một lần và mã thông báo thời gian, vì vậy, theo lý thuyết, mỗi khi người dùng đăng nhập.
Mặc dù điều này được cho là lạc đề, một miếng đệm một lần dường như là một giải pháp ưu việt.
Tương tự, và cơ bản hơn, đảm bảo rằng người dùng tạo mật khẩu mạnh và hiểu đạo đức đằng sau chính sách bảo mật của bạn (đừng viết nó ra, đừng biến nó thành ngày sinh nhật của bạn, đừng đưa nó cho bất kỳ ai) sẽ đi nhiều xa hơn chỉ đơn giản là buộc họ phải thay đổi nó mỗi khoảng thời gian dựa trên lần thứ n.