it-swarm-vi.com

Tại sao các trang web thực hiện khóa sau ba lần thử mật khẩu không thành công?

Tôi biết lý do đằng sau không để các nỗ lực mật khẩu vô hạn - các nỗ lực vũ phu không phải là meatspace điểm yếu, mà là vấn đề với bảo mật máy tính - nhưng họ đã lấy số ba từ đâu?

Không phải là từ chối dịch vụ là mối quan tâm khi thực hiện chính sách khóa dễ dàng được kích hoạt?

Có nghiên cứu khó khăn nào cho thấy một số hoặc phạm vi tối ưu để lựa chọn trước khi khóa tài khoản cân bằng mối đe dọa bảo mật thực tế với khả năng sử dụng không?

Nghĩ về nó, tôi không thấy bất kỳ sự khác biệt bảo mật có thể đo lường nào giữa ba lần thử và 20 lần thử với độ phức tạp của mật khẩu thường được sử dụng ngày nay.

(Tôi biết váy này chủ quan, nhưng tôi đang tìm kiếm ý kiến ​​dựa trên đo lường)

107
Bradley Kreider

Gần đây, tại hội nghị OWASP AppSec 2010 ở Quận Cam, Bill Cheswick từ AT & T đã nói chuyện rất lâu về vấn đề này.

Tóm lại, không có nghiên cứu đầy đủ.

Từ lâu, đây là một số ý tưởng của anh ấy về việc khóa tài khoản ít đau đớn hơn:

  • Đừng đếm các lần thử mật khẩu trùng lặp (có lẽ họ nghĩ rằng họ đã nhập nhầm)
  • Tạo gợi ý mật khẩu về mật khẩu chính và không có thứ yếu (yếu)
  • Cho phép một bên đáng tin cậy chứng từ cho người dùng, để anh ta có thể thay đổi mật khẩu của mình.
  • Khóa tài khoản theo thời gian tăng dần
  • Nhắc nhở người dùng các quy tắc mật khẩu.
75
Zian Choy

Bất kỳ trang web nào tuân thủ Tiêu chuẩn bảo mật dữ liệu PCI phải tuân thủ các phần

  • 8.5.13 (Hạn chế các lần truy cập lặp lại bằng cách khóa ID người dùng sau không quá sáu lần thử)
  • 8.5,14 (Đặt thời lượng khóa thành ba mươi phút hoặc cho đến khi quản trị viên kích hoạt ID người dùng).

Thật không may là tại sao nhiều trang web chấp nhận thẻ tín dụng có chính sách khóa hà khắc, mặc dù các nhà thiết kế của họ có thể không nhất thiết phải đồng ý với những gì họ đã thực hiện.

Chỉnh sửa: Lưu ý rằng các yêu cầu này chỉ áp dụng cho các hệ thống dành cho "người dùng không sử dụng" nên chúng không ảnh hưởng đến các trang web của khách hàng chấp nhận thẻ.

37
realworldcoder

Kinh nghiệm của tôi là các cơ chế khóa đang giảm dần về mức độ phổ biến (ít nhất là đối với các ứng dụng web). Thay vì khóa tài khoản sau một loạt các lần thử thất bại, bạn bắt đầu yêu cầu thêm thông tin để xác thực thành công.

22
Tate Hansen

Sẽ không ngạc nhiên nếu nó đến từ quy tắc "Ba cú đánh" bóng chày hơn là bất cứ thứ gì về mặt kỹ thuật.

Một cách biện minh (đối với mật khẩu chữ số dù sao) là

Thông thường, một lần thử thất bại là loại sai hoặc vấn đề bật/tắt CAPS. Vì vậy, bạn cố gắng đăng nhập và bị từ chối (1), thử lại vì bạn nghĩ rằng bạn đã nhập sai (2) và sau đó nhận ra khóa CAPS được bật để bạn tham gia vào lần thử thứ ba.

Không thực sự giữ để mở khóa điện thoại di động từ một mạng khi nó thường được nhập mã số.

Đề xuất tốt hơn là một sự chậm trễ ngày càng tăng giữa các lần đăng nhập thất bại liên tiếp. Trước tiên, bạn cho phép thử lại ngay lập tức, sau đó 1 giây, 2, bốn, tám ... Bạn đang nhanh chóng chờ đợi một phút giữa các lần thử đủ để đối phó với bất kỳ cuộc tấn công vũ phu nào.

18
Gary

Tôi đồng ý với OP. Nếu bạn nghĩ về những gì khóa bảo vệ bạn chống lại, không có sự khác biệt giữa 3 hoặc 20 lần thử (hoặc 100, cho vấn đề đó). Tất cả những gì bạn đạt được với các khóa này, ngoài việc trừng phạt những người dùng hay quên, là để ngăn chặn một cuộc tấn công vũ phu. Bạn cũng có thể sử dụng nó để kích hoạt cảnh báo rằng một cuộc tấn công đang diễn ra, nhưng đó không phải là mục đích chính (nếu có, điều đó có nghĩa là bạn đang cố tình làm cho người dùng của bạn chỉ để làm cho công việc giám sát của bạn dễ dàng hơn. thực hành rất tốt).

Nếu ai đó có cơ sở dữ liệu mật khẩu của bạn và có thể tấn công ngoại tuyến, họ sẽ thử không giới hạn. Giới hạn 20 lần đoán của bạn là không tốt ở đó.

Nếu ai đó đang cố gắng dùng vũ lực trực tuyến, tất cả những gì bạn cần là một mật khẩu có thể chịu được "đủ lâu": đủ lâu để IRT của bạn phản hồi hoặc đủ lâu để kẻ tấn công của bạn từ bỏ.

Cơ sở dữ liệu mật khẩu Conficker thấp hơn 200 mật khẩu, IIRC và nó chứa đầy một số mật khẩu ngu ngốc nhất trên hành tinh. Bây giờ hãy giả sử rằng mật khẩu của bạn không có trong danh sách này. Nếu bạn cho phép 20 lần thử mật khẩu, cứ sau 15 phút, không khóa, sẽ có kẻ tấn công mất hơn hai giờ chỉ để vượt qua danh sách đó.

Trên thực tế, ngay cả khi bạn thu hẹp danh sách đoán của mình xuống các mật khẩu được tạo từ thông tin có liên quan về người dùng đó, như Kidsname02, birthday99, v.v., bạn vẫn sẽ kết thúc với ít nhất vài chục mật khẩu, kéo dài cuộc tấn công từ điển thành có thể một giờ hoặc hơn. Việc đoán liên tục, sai lầm theo thời gian là điều sẽ kích hoạt báo động của bạn, không phải là một số mật khẩu sai trong vài phút.

Vì vậy, nếu bạn có thể giữ người dùng của mình tránh khỏi những cạm bẫy mật khẩu cơ bản nhất, bạn có thể vui vẻ chấp nhận rất nhiều lần thử mật khẩu sai.

Cá nhân, tôi vẽ đường ở mức 15. Hoàn toàn tùy ý và chủ yếu là một điều thực tế: Tôi thấy rằng bất kỳ người dùng thực sự nào đã từ bỏ từ lâu trước khi điều này. Thông thường nếu có nhiều cố gắng, đó là một quá trình hoặc phiên được treo ở đâu đó với thông tin cũ. Và nếu đó không phải là trường hợp, thì chúng ta có thể nói về việc tìm kiếm các cuộc tấn công.

15
itinsecurity

Đó là một quy tắc độc đoán ngớ ngẩn đi kèm với nguy cơ xảy ra một loại tấn công DDOS kỳ lạ. Hãy nói rằng Marv ghét trang web X và trang web X có chính sách khóa số Y. Marv có thể gây ra một số địa ngục nghiêm trọng bằng cách có một kịch bản tự động thử tên ngẫu nhiên Y lần với mật khẩu không có thật. Ngay cả khi mật khẩu hoạt động, Marv có thể sẽ không quan tâm và bỏ qua nó. Điều này sẽ khóa nhiều người dùng cho trang web X một cách hiệu quả và gây ra nhiều sự thất vọng cho người dùng và thần sẽ giúp đỡ họ nếu họ là ngân hàng mà bạn cần gọi để đặt lại mật khẩu. Tôi ngạc nhiên không ai đã thử điều này.

11
AmaDaden

Tôi tin rằng tôi đến trễ cuộc tranh luận này, nhưng tôi hy vọng tôi có một cái gì đó hữu ích để thêm vào đây.

Chính sách khóa tài khoản (với số lần thử không hợp lệ liên tiếp thường trong phạm vi các chữ số đơn cho hầu hết các tổ chức) không được đưa ra chỉ để chống lại các cuộc tấn công vũ phu tự động.

Nó là một sự bảo vệ chống lại việc đoán mật khẩu của những kẻ tấn công con người, đặc biệt là bởi những cá nhân đã biết về một phần của mật khẩu. Kẻ tấn công có thể có được các mảnh mật khẩu bằng cách

  • lướt vai
  • bằng cách đoán các mẫu được sử dụng bởi một cá nhân để chọn mật khẩu của họ. Rốt cuộc, có bao nhiêu lần một mật khẩu đã sử dụng với các thành phần trong một chuỗi, như mật khẩu # 01 , mật khẩu # 02 v.v.

Tất nhiên, nhược điểm là với giá trị ngưỡng thấp, chắc chắn sẽ có sự từ chối dịch vụ và chi phí liên quan đến kinh doanh. Sách trắng thực hành khóa tài khoản tốt nhất do Microsoft phát hành, cung cấp giá trị được đề xuất là 10. Nó cũng giải thích cách ước tính xác suất tấn công thành công, sử dụng các tham số trong chính sách khóa tài khoản của Windows:

Ví dụ: giả sử rằng quản trị viên đặt lại mật khẩu khi tài khoản bị khóa với giá trị đăng ký LockoutDuration bằng 0. Với giá trị đăng ký LockoutDuration được đặt thành 0 và giá trị đăng ký LockoutThrưỡng được đặt thành 20, người dùng độc hại có 20 lần đoán để sử dụng. mật khẩu. Nếu thời lượng khóa là 30 phút, người dùng độc hại có 20 lần đoán sau mỗi 30 phút đối với mật khẩu đó cho đến khi nó được thay đổi. Đây là một sự khác biệt rất đáng kể trong tổng số lần đoán có sẵn cho người dùng độc hại.

So sánh, nếu quản trị viên đặt tuổi mật khẩu tối đa là 42 ngày, thì người dùng độc hại đầu tiên chỉ có 20 lần đoán với bất kỳ mật khẩu cụ thể nào, trong khi người dùng độc hại thứ hai có 40.320 lần đoán (20 lần thử khóa, nhân với 48 lần khóa mỗi ngày, nhân với 42 ngày trước khi người dùng thay đổi mật khẩu). Với cài đặt mật khẩu mặc định, có khoảng 10 ^ 12 mật khẩu có thể. Điều này có nghĩa là người dùng độc hại có khoảng 0,000004 phần trăm (%) cơ hội đoán mật khẩu. Với sơ đồ đoán tối ưu, phần trăm này rất có thể sẽ là phần trăm lớn hơn.

Tất nhiên, không dễ để bất kỳ giáo dân nào chọn được một con số phù hợp, và những quyết định như vậy phải được xem xét cẩn thận. Do đó, có thể giả định một cách an toàn rằng một số tổ chức đã không nỗ lực để tính toán các tác động tiền tệ của chính sách khóa tài khoản của họ và lợi ích liên quan đến việc nới lỏng chính sách của họ trong khi vẫn giữ được lợi ích bảo mật mà nó mang lại.

10
Vineet Reynolds

Có hai khía cạnh này; đầu tiên, như bạn đề cập, là ngăn chặn các cuộc tấn công vũ phu.

Với mục đích này, thực sự bất kỳ số lần thử nào cũng nên thực hiện - 3, 5, 20, 2000 ... với chính sách mật khẩu phù hợp (độ dài + độ phức tạp + ...) mang lại một không gian khóa đủ lớn, any loại điều chỉnh (số lần thử X mỗi giờ) sẽ đảm bảo rằng vũ phu buộc toàn bộ không gian sẽ mất khá nhiều thập kỷ. (Làm toán).

Ngay cả khi - và đây phải là một yêu cầu - việc khóa chỉ là tạm thời và sau một thời gian ngắn, nó sẽ tự động mở khóa.

Do đó, số lần thử trước khi khóa là tùy ý.

Tuy nhiên, có một vấn đề khác, tinh tế hơn, phi toán học đang diễn ra ở đây:

Nó chỉ đơn giản là không có ý nghĩa đối với một người dùng liên tục đặt sai mật khẩu 2000 lần liên tiếp.

Nghĩa là, nếu bạn tùy ý chọn 2000, bạn sẽ biết dài trước đó thì đây KHÔNG phải là người dùng hợp pháp. Vì vậy, nó thực sự đi vào những gì có ý nghĩa kinh doanh và một sự đánh đổi phân tích rủi ro tập trung vào kinh doanh.

Tôi nghĩ trong lịch sử, sự đánh đổi nghiêng về phía rủi ro hơn - vì mật khẩu ngắn hơn và ít phức tạp hơn, sự khác biệt của 3 hoặc 10 là lớn hơn. Ngoài ra, mọi người đã có ít hơn mật khẩu, vì vậy họ dễ nhớ hơn ... Và nói chung, người dùng hiểu biết nhiều về kỹ thuật hơn.

Ngày nay, ba thực sự không có ý nghĩa, xem xét tác động kinh doanh. Đây thực sự là một câu hỏi về ý nghĩa của your ứng dụng, loại người dùng nào, tần suất họ đăng nhập, v.v. Tôi thường khuyên bạn nên tìm hiểu xem có bao nhiêu lần thất bại, có thể xảy ra hợp pháp, sau đó tăng gấp đôi nó.

( Như @realworldcoder đã đề cập , PCI tùy ý chọn sáu và nếu bạn là đối tượng của PCI, bạn không có nhiều quyết định ở đây. Nếu không, hãy chọn một số có ý nghĩa với bạn.)

8
AviD

Liên quan đến các đề xuất về việc tăng thời gian 'khóa máy' để trì hoãn các lần thử thất bại liên tiếp và do đó ngăn chặn sự ép buộc, xin vui lòng nhớ điều này chỉ hoạt động đối với các cuộc tấn công của người dùng được nhắm mục tiêu.

Nếu kẻ tấn công chỉ quan tâm đến việc xâm nhập hệ thống, họ có thể thực hiện cuộc tấn công đầu tiên theo chiều rộng (Chu kỳ tất cả tên người dùng đã biết/đoán trước khi chuyển sang mật khẩu tiếp theo). Thêm vào đó, nếu nó được thực hiện đúng cách, nó có thể đến từ một mạng máy phân tán, khá dễ dàng để thấy rằng hệ thống trì hoãn cũng không hoạt động.

Như đã đề cập bởi những người khác, việc theo dõi chính xác các nỗ lực thất bại để phát hiện ra các cuộc tấn công sớm là rất quan trọng.

Có, 3 lần thử là khá tùy tiện và có rủi ro DoS. Tôi thực sự mong mọi người sẽ ngừng sử dụng cho các hệ thống đối mặt với công chúng ... Xin vui lòng!

Một giải pháp khác: xác định 2 yếu tố. Mã thông báo RSA. Giá như chúng tôi có cách sở hữu cá nhân một mã thông báo RSA duy nhất với 'số id'. Sau đó, chúng tôi có thể đăng ký 'số id' này với bất kỳ hệ thống nào, sau đó sẽ yêu cầu giá trị hiện tại từ mã thông báo cùng với mật khẩu để đăng nhập.

Nhưng điều đó đặt ra một loạt các vấn đề khác để thực hiện và tin tưởng ...

7
Dan McGrath

Các công ty là công chúng (bán cổ phiếu tại các sàn giao dịch chứng khoán) được quy định theo Đạo luật Sarbanes-Oxley và được kiểm toán nhiều lần trong năm để tuân thủ. Các ứng dụng phần mềm quan trọng phải tuân thủ một số tính năng bảo mật nhất định là một trong số chúng để khóa tài khoản sau khi thử mật khẩu không thành công.

Phần lớn các ứng dụng này, những gì họ làm là tích hợp vào Active Directory của công ty đã kích hoạt các tính năng.

3
Jose

Đây một bài đọc thực sự hay đi qua những gì tôi tin rằng bạn đang tìm kiếm. Họ đã lấy dữ liệu từ sinh viên đại học bằng chính sách ba lần đình công, chính sách mười lần đình công và chính sách đình công vô hạn để đề nghị chúng tôi tăng số lượng từ ba lên mười (vì nó tăng gấp ba lần thành công của việc đăng nhập).

Trở lại vào một cái nhìn chủ quan ở đây ...

Tại sao hầu hết các nơi sử dụng chính sách ba cuộc đình công? Nó chắc chắn chỉ là một heuristic phát triển theo thời gian. Ba lần thử ít nhiều là một nền tảng trung gian cho các quản trị viên và người dùng, trong đó ba cơ hội là quá đủ.

Ý tưởng đằng sau một mật khẩu là bạn được cho là để biết nó. Bạn thực sự không nên cần nhiều hơn một lần thử. Tôi hiểu rằng những sai lầm đã được tạo ra, nhưng trong một cuộc chiến ... bạn thực sự chỉ có một cơ hội để chứng minh bạn là đồng minh, phải không?.

3
user124863

Họ phải chọn 3 ngẫu nhiên. Điều này là cực kỳ thấp. Có lẽ họ đã có vấn đề về bảo mật trong quá khứ và đã chọn số khóa thấp thay vì giải quyết hoặc khắc phục vấn đề một cách chính xác.

Tôi thích phương pháp khóa người dùng theo thời gian tăng dần. Mặc dù vậy, tôi sẽ không khóa tên người dùng, thay vào đó sử dụng địa chỉ IP của người đó, vì người đó có thể đang thử nhiều tên người dùng. Tôi đặt thời gian khóa thành (số lần đăng nhập không hợp lệ) ^ 2 giây, khi người dùng đã đạt 5 lần thử không hợp lệ. Nếu người dùng không biết mật khẩu của họ với số lần thử tương đối thấp, họ sẽ chủ yếu sử dụng công cụ khôi phục mật khẩu nếu trang web cung cấp một mật khẩu. Nếu đó là một nỗ lực hack thực sự, nó sẽ trở nên gây khó chịu cho tin tặc đến nỗi cuối cùng họ sẽ bỏ cuộc. Bots sẽ thử rất nhiều lần họ gần như sẽ không bao giờ được phép đăng nhập ... ví dụ: nếu họ đã thử 1000 mật khẩu (sẽ mất nhiều thời gian để thực sự làm bất cứ cách nào), họ sẽ phải đợi 11 tiếng rưỡi trước khi có thể thử mật khẩu thứ 1001. Bạn có thể dễ dàng tăng khả năng răn đe bằng cách tăng hệ số nhân lên ^ 3. Bất cứ điều gì ở trên có thể hơi quá cao đối với người dùng hợp lệ.

2
Rush Frisby

Cách đây không lâu, tôi đã thực hiện một chương trình bảo mật đăng nhập tuân theo các quy tắc cơ bản sau:

  1. Lần thử đầu tiên thất bại cho phản hồi ngay lập tức. Có lẽ họ béo ngón tay.
  2. Lần thử thứ hai đến thứ năm không thành công khiến phản hồi bị trì hoãn một giây cho mỗi lần thử thất bại. ví dụ: 2 giây, 3 giây, 4 giây ...
  3. Nếu lần thử thứ năm không thành công, thì phiên kết thúc và họ được thông báo cho biết họ sẽ phải đóng trình duyệt và thử lại.

Đối với tôi điều này là quá đủ để ngăn chặn các cuộc tấn công vũ phu; nhiều nhất sẽ gây bất tiện cho người dùng cuối và không tạo thêm bất kỳ công việc nào để được hỗ trợ.

2
Josh