Biện pháp đối phó Brute Force tốt nhất là gì?

Đầu tiên, một nền tảng nhỏ: Không có gì bí mật khi tôi triển khai hệ thống auth + auth cho CodeIgniter, và cho đến nay tôi đang chiến thắng (có thể nói là như vậy). Nhưng tôi đã gặp phải một thách thức không hề nhỏ (một điều mà hầu hết các thư viện xác thực đều bỏ lỡ hoàn toàn, nhưng tôi khăng khăng xử lý nó đúng cách): làm thế nào để đối phó một cách thông minh với các cuộc tấn công vũ trang có tên người dùng biến đổi, phân tán, quy mô lớn .

Tôi biết tất cả các thủ thuật thông thường:

1. Giới hạn # lần thử thất bại trên mỗi IP / máy chủ và từ chối quyền truy cập của người phạm tội (ví dụ Fail2Ban) - không còn hoạt động do botnet đã phát triển thông minh hơn
2. Kết hợp những điều trên với một danh sách đen các IP / máy chủ 'xấu' đã biết (ví dụ: Denyhost) - dựa trên các botnet rơi vào vị trí số 1, mà chúng ngày càng không
3. Danh sách trắng IP / máy chủ lưu trữ kết hợp với xác thực truyền thống (đáng buồn là vô dụng với người dùng IP động và tốc độ cao trên hầu hết các trang web)
4. Đặt giới hạn thời gian chờ cho # lần thử không thành công trong khoảng thời gian N phút / giờ và điều chỉnh (tạm dừng) tất cả các lần thử đăng nhập sau đó trong một vài phút / giờ (với vấn đề DoS tấn công bạn trở thành trò chơi của botnet)
5. Chữ ký kỹ thuật số bắt buộc (chứng chỉ khóa công khai) hoặc mã thông báo phần cứng RSA cho tất cả người dùng không có tùy chọn đăng nhập / mật khẩu (không có câu hỏi về giải pháp vững chắc, nhưng chỉ thực tế đối với các dịch vụ chuyên dụng, đóng)
6. Các lược đồ mật khẩu cực mạnh được thực thi (ví dụ> 25 ký tự vô nghĩa có ký hiệu - một lần nữa, quá không thực tế đối với người dùng thông thường)
7. Và cuối cùng, CAPTCHA (có thể hoạt động trong hầu hết các trường hợp, nhưng gây khó chịu cho người dùng và hầu như vô dụng trước kẻ tấn công kiên quyết, tháo vát )

Bây giờ, đây chỉ là những ý tưởng khả thi về mặt lý thuyết. Có rất nhiều ý tưởng rác rưởi thổi tung trang web rộng mở (ví dụ như các cuộc tấn công DoS tầm thường). Những gì tôi muốn là một cái gì đó tốt hơn. Và tốt hơn, ý tôi là:

• Nó phải được bảo mật (+) trước các cuộc tấn công của DoS và vũ phu, và không đưa ra bất kỳ lỗ hổng mới nào có thể cho phép một bot lén lút hơn một chút tiếp tục hoạt động dưới radar

• Nó phải được tự động hóa. Nếu nó yêu cầu một nhà điều hành con người xác minh từng đăng nhập hoặc theo dõi hoạt động đáng ngờ, thì nó sẽ không hoạt động trong một kịch bản trong thế giới thực

• Nó phải khả thi cho việc sử dụng web chính thống (ví dụ: khuấy cao, khối lượng lớn và đăng ký mở có thể được thực hiện bởi những người không lập trình)

• Nó không thể cản trở trải nghiệm người dùng đến mức người dùng thông thường sẽ cảm thấy khó chịu hoặc bực bội (và có khả năng từ bỏ trang web)

• Nó không liên quan đến mèo con, trừ khi chúng thực sự là mèo con an toàn

(+) Bởi 'an toàn', ý tôi là ít nhất là an toàn như khả năng của người dùng hoang tưởng để giữ bí mật mật khẩu của mình

Vì vậy - hãy nghe nó! Làm thế nào bạn sẽ làm điều đó ? Bạn có biết về một thực hành tốt nhất mà tôi chưa đề cập (oh xin vui lòng nói bạn làm)? Tôi thừa nhận tôi có một ý tưởng của riêng mình (kết hợp các ý tưởng từ 3 và 4), nhưng tôi sẽ để các chuyên gia thực sự nói trước khi lúng túng ;-)

Được rồi, đủ đình trệ; Đây là những gì tôi nghĩ ra cho đến nay

(xin lỗi, bài viết dài phía trước. Hãy dũng cảm, bạn ạ, cuộc hành trình sẽ có giá trị)

Kết hợp các phương pháp 3 và 4 từ bài đăng gốc thành một loại 'danh sách mờ' hoặc danh sách trắng động, và sau đó - và đây là mẹo - không chặn các IP không có trong danh sách trắng, chỉ cần đẩy chúng xuống địa ngục và quay lại .

Lưu ý rằng biện pháp này chỉ nhằm ngăn chặn kiểu tấn công rất cụ thể này. Trong thực tế, tất nhiên, nó sẽ hoạt động kết hợp với các cách tiếp cận thực tiễn tốt nhất khác để xác thực: điều chỉnh tên người dùng cố định, điều chỉnh trên mỗi IP, chính sách mật khẩu mạnh được thực thi bằng mã, đăng nhập cookie không được lưu trữ, băm tất cả các mật khẩu tương đương trước khi lưu chúng, không bao giờ sử dụng câu hỏi bảo mật, vv

Giả định về kịch bản tấn công

Nếu kẻ tấn công đang nhắm mục tiêu tên người dùng khác nhau, điều chỉnh tên người dùng của chúng tôi sẽ không kích hoạt. Nếu kẻ tấn công đang sử dụng botnet hoặc có quyền truy cập vào phạm vi IP lớn, việc điều chỉnh IP của chúng tôi là bất lực. Nếu kẻ tấn công đã quét trước danh sách người dùng của chúng tôi (thường có thể trên các dịch vụ web đăng ký mở), chúng tôi không thể phát hiện một cuộc tấn công đang diễn ra dựa trên số lỗi 'không tìm thấy người dùng'. Và nếu chúng tôi thực thi điều tiết toàn hệ thống hạn chế (tất cả tên người dùng, tất cả IP), thì bất kỳ cuộc tấn công nào như vậy sẽ làm toàn bộ trang web của chúng tôi trong suốt thời gian của cuộc tấn công cộng với thời gian điều tiết.

Vì vậy, chúng ta cần phải làm một cái gì đó khác.

Phần đầu tiên của biện pháp đối phó: Danh sách trắng

Điều chúng ta có thể khá chắc chắn, đó là kẻ tấn công không thể phát hiện và tự động giả mạo địa chỉ IP của hàng ngàn người dùng của chúng tôi (+). Mà làm cho danh sách trắng khả thi. Nói cách khác: đối với mỗi người dùng, chúng tôi lưu trữ một danh sách các IP (được băm) từ nơi người dùng đã đăng nhập trước đó (gần đây).

Do đó, chương trình danh sách trắng của chúng tôi sẽ hoạt động như một 'cửa trước' bị khóa, trong đó người dùng phải được kết nối từ một trong những IP 'tốt' được công nhận của mình để đăng nhập. Một cuộc tấn công vũ phu vào 'cửa trước' này thực tế là không thể (+).

. -tìm tình huống FUBAR

Phần thứ hai của biện pháp đối phó: Điều chỉnh toàn bộ hệ thống của các IP không được nhận dạng

Để làm cho danh sách trắng hoạt động cho dịch vụ web đăng ký mở, nơi người dùng chuyển đổi máy tính thường xuyên và / hoặc kết nối từ địa chỉ IP động, chúng tôi cần mở 'cửa mèo' cho người dùng kết nối từ các IP không được nhận dạng. Bí quyết là thiết kế cánh cửa đó để botnet bị kẹt, và vì vậy người dùng hợp pháp bị làm phiền ít nhất có thể .

Trong sơ đồ của tôi, điều này đạt được bằng cách đặt số lần đăng nhập thất bại tối đa rất hạn chế bởi các IP không được chấp thuận trong khoảng thời gian 3 giờ (có thể khôn ngoan hơn khi sử dụng thời gian ngắn hơn hoặc dài hơn tùy thuộc vào loại dịch vụ) và làm cho hạn chế đó toàn cầu , tức là. cho tất cả các tài khoản người dùng.

Ngay cả một lực lượng vũ phu chậm (1-2 phút giữa các lần thử) sẽ được phát hiện và ngăn chặn nhanh chóng và hiệu quả bằng phương pháp này. Tất nhiên, một lực lượng vũ phu thực sự chậm vẫn có thể không được chú ý, nhưng tốc độ quá chậm đánh bại mục đích chính của cuộc tấn công vũ phu.

Điều tôi hy vọng đạt được với cơ chế tiết lưu này là nếu đạt đến giới hạn tối đa, 'cửa mèo' của chúng tôi đóng lại trong một thời gian, nhưng cửa trước của chúng tôi vẫn mở cho người dùng hợp pháp kết nối bằng các phương tiện thông thường:

• Bằng cách kết nối từ một trong những IP được công nhận của họ
• Hoặc bằng cách sử dụng cookie đăng nhập liên tục (từ bất cứ đâu)

Người dùng hợp pháp duy nhất sẽ bị ảnh hưởng trong một cuộc tấn công - tức là. trong khi điều chỉnh được kích hoạt - sẽ là người dùng không có cookie đăng nhập liên tục, những người đang đăng nhập từ một vị trí không xác định hoặc bằng một IP động. Những người dùng đó sẽ không thể đăng nhập cho đến khi điều tiết bị tắt (điều này có thể mất một thời gian, nếu kẻ tấn công giữ botnet của anh ta chạy mặc dù điều tiết).

Để cho phép nhóm người dùng nhỏ này siết chặt cửa mèo bịt kín, ngay cả khi các bot vẫn đang cố gắng sử dụng nó, tôi sẽ sử dụng mẫu đăng nhập 'sao lưu' với CAPTCHA. Vì vậy, khi bạn hiển thị thông báo "Xin lỗi, nhưng bạn không thể đăng nhập từ địa chỉ IP này vào lúc này", bao gồm một liên kết có nội dung " đăng nhập sao lưu an toàn - CHỈ CÓ CON NGƯỜI ( bot: không nói dối ) ". Đùa sang một bên, khi họ nhấp vào liên kết đó, hãy cung cấp cho họ một hình thức đăng nhập được xác thực reCAPTCHA mà bỏ qua điều chỉnh trên toàn trang web. Bằng cách đó, NẾU họ là con người VÀ biết mật khẩu đăng nhập + chính xác (và có thể đọc CAPTCHA), họ sẽ không bao giờ bị từ chối dịch vụ, ngay cả khi họ đang kết nối từ một máy chủ không xác định và không sử dụng cookie tự động.

Ồ, và chỉ để làm rõ: Vì tôi thực sự coi CAPTCHA là xấu, nên tùy chọn đăng nhập 'sao lưu' sẽ chỉ xuất hiện khi điều chỉnh hoạt động .

Không thể phủ nhận rằng một cuộc tấn công được duy trì như thế vẫn sẽ tạo thành một hình thức tấn công DoS, nhưng với hệ thống được mô tả, nó sẽ chỉ ảnh hưởng đến những gì tôi nghi ngờ là một tập hợp con nhỏ của người dùng, cụ thể là những người không sử dụng Cookie "nhớ tôi" VÀ tình cờ đăng nhập trong khi một cuộc tấn công đang xảy ra VÀ không đăng nhập từ bất kỳ IP thông thường nào của họ VÀ những người không thể đọc CAPTCHA. Chỉ những người có thể nói không với TẤT CẢ các tiêu chí đó - cụ thể là bot và những người khuyết tật thực sự không may mắn - sẽ bị từ chối trong một cuộc tấn công bot.

EDIT: Thực tế, tôi đã nghĩ ra một cách để cho phép ngay cả những người dùng bị thách thức CAPTCHA vượt qua trong khi 'khóa máy': thay vì, hoặc như một phần bổ sung cho đăng nhập CAPTCHA dự phòng, cung cấp cho người dùng một tùy chọn để sử dụng một lần , mã khóa cụ thể của người dùng được gửi đến email của anh ta, sau đó anh ta có thể sử dụng để bỏ qua điều tiết. Điều này chắc chắn vượt qua ngưỡng 'phiền toái' của tôi, nhưng vì nó chỉ được sử dụng như là phương sách cuối cùng cho một nhóm nhỏ người dùng và vì nó vẫn bị khóa khỏi tài khoản của bạn, nên có thể chấp nhận được.

(Ngoài ra, lưu ý rằng không có điều này xảy ra nếu cuộc tấn công kém tinh vi hơn phiên bản phân tán khó chịu mà tôi đã mô tả ở đây. Nếu cuộc tấn công đến từ chỉ một vài IP hoặc chỉ đánh một vài tên người dùng, nó sẽ bị cản trở sớm hơn nhiều và không có hậu quả trên toàn trang web)

Vì vậy, đó là biện pháp đối phó mà tôi sẽ thực hiện trong thư viện xác thực của mình, một khi tôi tin rằng đó là âm thanh và đó không phải là một giải pháp đơn giản hơn nhiều mà tôi đã bỏ lỡ. Thực tế là, có rất nhiều cách tinh tế để làm những điều sai trái trong bảo mật, và tôi không ở trên đưa ra những giả định sai lầm hoặc logic thiếu sót vô vọng. Vì vậy, xin vui lòng, bất kỳ và tất cả thông tin phản hồi, chỉ trích và cải tiến, tinh tế, vv được đánh giá cao.

Một vài bước đơn giản:

Danh sách đen một số tên người dùng phổ biến và sử dụng chúng như một honeypot. Quản trị viên, khách, v.v ... Đừng để ai tạo tài khoản với những tên này, vì vậy nếu ai đó cố gắng đăng nhập họ thì bạn biết đó là ai đó không nên làm gì đó.

Hãy chắc chắn rằng bất cứ ai có quyền lực thực sự trên trang web đều có mật khẩu an toàn. Yêu cầu quản trị viên / người kiểm duyệt phải có mật khẩu dài hơn với sự kết hợp của các chữ cái, số và ký hiệu. Từ chối các mật khẩu đơn giản tầm thường từ người dùng thông thường với một lời giải thích.

Một trong những điều đơn giản nhất bạn có thể làm là nói với mọi người khi ai đó cố gắng đăng nhập vào tài khoản của họ và cung cấp cho họ liên kết để báo cáo sự việc nếu đó không phải là họ. Một tin nhắn đơn giản khi họ đăng nhập như "Ai đó đã cố đăng nhập vào tài khoản của bạn lúc 4:20 sáng thứ tư blah blah. Nhấp vào đây nếu đây không phải là bạn." Nó cho phép bạn giữ một số thống kê về các cuộc tấn công. Bạn có thể đẩy mạnh các biện pháp giám sát và bảo mật nếu bạn thấy rằng có sự gia tăng đột ngột số lượt truy cập gian lận.

Nếu tôi hiểu MO của các cuộc tấn công vũ phu đúng cách, thì một hoặc nhiều tên người dùng sẽ được thử liên tục.

Có hai gợi ý mà tôi không nghĩ rằng tôi đã thấy ở đây:

• Tôi luôn nghĩ rằng thông lệ tiêu chuẩn là có độ trễ ngắn (một giây hoặc lâu hơn) sau mỗi lần đăng nhập sai cho mỗi người dùng. Điều này ngăn chặn sức mạnh vũ phu, nhưng tôi không biết một giây chậm trễ sẽ khiến cuộc tấn công từ điển bị kéo dài bao lâu. (từ điển 10.000 từ == 10.000 giây == khoảng 3 giờ. Hmm. Không đủ tốt.)
• thay vì làm chậm toàn bộ trang web, tại sao không phải là một van tiết lưu tên người dùng. Van tiết lưu ngày càng trở nên khắc nghiệt với mỗi lần thử sai (đến một giới hạn, tôi đoán để người dùng thực sự vẫn có thể đăng nhập)

Chỉnh sửa : Đáp lại các bình luận về một bộ điều tiết tên người dùng: đây là một bộ điều tiết cụ thể của tên người dùng mà không liên quan đến nguồn gốc của cuộc tấn công.

Nếu tên người dùng được điều chỉnh, thì ngay cả một cuộc tấn công tên người dùng được phối hợp (nhiều IP, một lần đoán cho mỗi IP, cùng tên người dùng) sẽ bị bắt. Tên người dùng cá nhân được bảo vệ bởi van tiết lưu, ngay cả khi những kẻ tấn công có thể tự do thử một người dùng / vượt qua khác trong thời gian chờ.

Từ quan điểm của kẻ tấn công, trong thời gian chờ, bạn có thể đoán lần đầu tiên với 100 mật khẩu và nhanh chóng phát hiện ra một mật khẩu sai cho mỗi tài khoản. Bạn chỉ có thể đoán 50 giây trong cùng khoảng thời gian.

Từ quan điểm tài khoản người dùng, vẫn có cùng số lần đoán trung bình để phá mật khẩu, ngay cả khi các lần đoán đến từ nhiều nguồn.

Đối với những kẻ tấn công, tốt nhất, sẽ là cùng một nỗ lực để phá vỡ 100 tài khoản như 1 tài khoản, nhưng vì bạn không điều tiết trên cơ sở rộng khắp trang web, bạn có thể tăng tốc khá nhanh.

Tinh chỉnh thêm:

• phát hiện các IP đang đoán nhiều tài khoản - 408 Yêu cầu Hết giờ
• phát hiện các IP đang đoán cùng một tài khoản - 408 Yêu cầu hết thời gian chờ sau một số lượng lớn (giả sử 100) số lần đoán.

Ý tưởng UI (có thể không phù hợp trong bối cảnh này), cũng có thể tinh chỉnh những điều trên:

• nếu bạn kiểm soát cài đặt mật khẩu, thì hãy cho người dùng thấy mật khẩu của họ mạnh đến mức nào để khuyến khích họ chọn mật khẩu tốt hơn.
• nếu bạn đang kiểm soát trang đăng nhập , sau một số lượng nhỏ (giả sử 10) số lần đoán của một tên người dùng, hãy cung cấp CAPTCHA.

Có ba yếu tố xác thực:

1. Một người dùng biết một cái gì đó (ví dụ, một mật khẩu)
2. Một người dùng có một cái gì đó (ví dụ, một khóa fob)
3. Một người dùng là một cái gì đó (ví dụ, quét võng mạc)

Thông thường, các trang web chỉ thực thi chính sách # 1. Thậm chí, hầu hết các ngân hàng chỉ thực thi chính sách 1. Thay vào đó họ dựa vào cách tiếp cận "biết điều gì khác" để xác thực hai yếu tố. (IE: Một người dùng biết mật khẩu của họ và tên thời con gái của mẹ họ.) Nếu bạn có thể, một cách để thêm vào yếu tố xác thực thứ hai không quá khó.

Nếu bạn có thể tạo khoảng 256 ký tự ngẫu nhiên, bạn có thể cấu trúc nó trong bảng 16 × 16, sau đó yêu cầu người dùng cung cấp cho bạn giá trị trong bảng của ô A-14 chẳng hạn. Khi người dùng đăng ký hoặc thay đổi mật khẩu của họ, hãy đưa cho họ bảng và bảo họ in nó ra và lưu lại.

Khó khăn với cách tiếp cận đó là khi người dùng quên mật khẩu của họ, như họ sẽ làm, bạn không thể đưa ra "trả lời câu hỏi này và nhập mật khẩu mới", vì điều đó cũng dễ bị tấn công. Ngoài ra, bạn không thể đặt lại nó và gửi email cho họ một cái mới, vì email của họ cũng có thể bị xâm phạm. (Xem: Makeuseof.com và tên miền bị đánh cắp của họ.)

Một ý tưởng khác (liên quan đến mèo con), là cái mà BOA gọi là SiteKey (tôi tin rằng chúng đã đăng ký tên thương hiệu). Tóm lại, bạn có người dùng tải lên một hình ảnh khi họ đăng ký và khi họ cố gắng đăng nhập, hãy yêu cầu họ chọn hình ảnh của họ trong số 8 hoặc 15 (hoặc nhiều hơn) những hình ảnh ngẫu nhiên. Vì vậy, nếu người dùng tải lên hình ảnh của mèo con của họ, về mặt lý thuyết chỉ họ biết chính xác bức ảnh đó là của họ trong số tất cả những chú mèo con khác (hoặc hoa hoặc bất cứ thứ gì). Khả năng duy nhất thực sự của phương pháp này là cuộc tấn công giữa chừng.

Một ý tưởng nữa (không có mèo con), là theo dõi IP mà người dùng truy cập hệ thống và yêu cầu họ thực hiện xác thực bổ sung (captcha, chọn mèo, chọn khóa từ bảng này) khi họ đăng nhập từ địa chỉ mà họ ẩn trước đây Ngoài ra, tương tự như Gmail, cho phép người dùng xem nơi họ đã đăng nhập gần đây.

Chỉnh sửa, ý tưởng mới:

Một cách khác để xác thực các lần thử đăng nhập là kiểm tra xem người dùng có đến từ trang đăng nhập của bạn hay không. Bạn không thể kiểm tra người giới thiệu, vì họ có thể dễ dàng giả mạo. Điều bạn cần là đặt một khóa trong _SESSION var khi người dùng xem trang đăng nhập, sau đó kiểm tra để đảm bảo rằng khóa đó tồn tại khi họ gửi thông tin đăng nhập. Nếu bot không gửi từ trang đăng nhập, nó sẽ không thể đăng nhập. Bạn cũng có thể tạo điều kiện thuận lợi cho việc này bằng cách liên quan đến javascript trong quá trình, bằng cách sử dụng nó để đặt cookie hoặc thêm một số thông tin vào biểu mẫu sau khi đã tải. Hoặc, bạn có thể chia biểu mẫu thành hai lần gửi khác nhau (nghĩa là người dùng nhập tên người dùng của họ, gửi, sau đó trên một trang mới nhập mật khẩu của họ và gửi lại.)

Chìa khóa, trong trường hợp này, là khía cạnh quan trọng nhất. Một phương pháp phổ biến để tạo ra chúng là một số kết hợp dữ liệu của người dùng, IP của họ và thời gian được gửi.

Trước đây tôi đã trả lời một câu hỏi tương tự tại Làm thế nào tôi có thể điều tiết các nỗ lực đăng nhập của người dùng trong PHP . Tôi sẽ nhắc lại giải pháp được đề xuất ở đây vì tôi tin rằng nhiều bạn sẽ thấy nó hữu ích và hữu ích khi xem một số mã thực tế. Xin lưu ý rằng việc sử dụng CAPTCHA có thể không phải là giải pháp tốt nhất do các thuật toán ngày càng chính xác đang được sử dụng trong bộ giảm giá CAPTCHA hiện nay:

Bạn không thể đơn giản ngăn chặn các cuộc tấn công DoS bằng cách xâu chuỗi xuống một IP hoặc tên người dùng. Quỷ thần, bạn thậm chí không thể thực sự ngăn chặn các nỗ lực đăng nhập nhanh chóng bằng phương pháp này.

Tại sao? Bởi vì cuộc tấn công có thể mở rộng nhiều IP và tài khoản người dùng với mục đích bỏ qua các nỗ lực điều chỉnh của bạn.

Tôi đã thấy đăng ở nơi khác rằng lý tưởng nhất là bạn nên theo dõi tất cả các lần đăng nhập thất bại trên trang web và liên kết chúng với dấu thời gian, có lẽ:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Quyết định về độ trễ nhất định dựa trên tổng số lần đăng nhập thất bại trong một khoảng thời gian nhất định. Bạn nên dựa trên dữ liệu thống kê được lấy từ failed_loginsbảng của mình vì nó sẽ thay đổi theo thời gian dựa trên số lượng người dùng và số người trong số họ có thể nhớ lại (và nhập) mật khẩu của họ.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Truy vấn bảng trên mỗi lần đăng nhập thất bại để tìm số lần đăng nhập thất bại trong một khoảng thời gian nhất định, giả sử 15 phút:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Nếu số lần thử trong khoảng thời gian nhất định vượt quá giới hạn của bạn, hãy thực thi điều tiết hoặc buộc tất cả người dùng sử dụng captcha (tức là reCaptcha) cho đến khi số lần thử không thành công trong khoảng thời gian nhất định nhỏ hơn ngưỡng.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Sử dụng reCaptcha ở một ngưỡng nhất định sẽ đảm bảo rằng một cuộc tấn công từ nhiều mặt trận sẽ được giảm thiểu và người dùng trang web bình thường sẽ không gặp phải sự chậm trễ đáng kể cho các lần thử đăng nhập thất bại hợp pháp. Tôi không thể phòng ngừa được bảo vệ, vì nó đã được mở rộng khi CAPTCHA có thể bị phá vỡ. Có những giải pháp thay thế, có lẽ là một biến thể của "Đặt tên cho con vật này", có thể hoạt động khá tốt như một sự thay thế.

Tôi phải hỏi liệu bạn đã thực hiện phân tích lợi ích chi phí cho vấn đề này chưa; có vẻ như bạn đang cố bảo vệ mình khỏi kẻ tấn công có đủ sự hiện diện web để đoán một số mật khẩu, có thể gửi 3-5 yêu cầu cho mỗi IP (vì bạn đã loại bỏ điều tiết IP). Loại tấn công đó sẽ tốn bao nhiêu (khoảng)? Có đắt hơn giá trị của các tài khoản bạn đang cố gắng bảo vệ không? Có bao nhiêu botnet khổng lồ muốn những gì bạn đã có?

Câu trả lời có thể là không - nhưng nếu có, tôi hy vọng bạn sẽ nhận được sự giúp đỡ từ một chuyên gia bảo mật nào đó; kỹ năng lập trình (và điểm StackOverflow) không tương quan mạnh mẽ với bí quyết bảo mật.

Để tóm tắt sơ đồ của Jens thành sơ đồ / quy tắc chuyển đổi trạng thái giả:

1. người dùng + mật khẩu -> mục
2. mật khẩu +! -> bị từ chối
3. người dùng + know_IP (người dùng) -> cửa trước, // never throttle
4. người dùng + unknown_IP (người dùng) -> catflap
5. (#denied> n) qua catflaps (trang web) -> catflaps (trang web) // slow the bots
6. catflap + ga + mật khẩu + captcha -> mục // humans still welcome
7. catflap + ga + mật khẩu +! captcha -> bị từ chối // a correct guess from a bot

Quan sát:

• Không bao giờ đạp ga cửa trước. Cảnh sát bang Elbon có máy tính của bạn, trong nhà bạn, nhưng không thể thẩm vấn bạn. Brute force là một cách tiếp cận khả thi từ máy tính của bạn.
• Nếu bạn cung cấp "Quên mật khẩu của bạn?" liên kết, sau đó tài khoản email của bạn trở thành một phần của bề mặt tấn công.

Những quan sát này bao gồm một kiểu tấn công khác với những cuộc tấn công mà bạn đang cố gắng chống lại.

Có vẻ như bạn đang cố gắng chống lại lực lượng vũ phu phân tán chậm . Không có nhiều bạn có thể làm về nó. Chúng tôi đang sử dụng PKI và không có thông tin đăng nhập mật khẩu. Nó giúp, nhưng nếu khách hàng của bạn có cơ hội làm việc mỗi lần một lần, điều này không được áp dụng nhiều.

Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho một công ty hai yếu tố, nhưng tôi không ở đây để cắm nó. Dưới đây là một số quan sát.

Cookies có thể bị đánh cắp với XSS và trình duyệt thô tục. Người dùng thường thay đổi trình duyệt hoặc xóa cookie của họ.

Địa chỉ IP nguồn đồng thời biến động và giả mạo.

Captcha là hữu ích, nhưng không xác thực một con người cụ thể.

Nhiều phương pháp có thể được kết hợp thành công, nhưng hương vị tốt chắc chắn là theo thứ tự.

Độ phức tạp của mật khẩu là tốt, bất cứ điều gì nghiêm trọng dựa trên mật khẩu đều phụ thuộc vào mật khẩu có đủ entropy. IMHO, một mật khẩu mạnh được ghi ở vị trí vật lý an toàn tốt hơn mật khẩu yếu trong bộ nhớ. Mọi người biết cách đánh giá tính bảo mật của tài liệu giấy tốt hơn nhiều so với họ biết cách tìm ra entropy hiệu quả trong tên chú chó của họ khi được sử dụng làm mật khẩu cho ba trang web khác nhau. Cân nhắc việc cung cấp cho người dùng khả năng in ra một trang lớn hoặc nhỏ chứa đầy đủ các mật mã sử dụng một lần.

Các câu hỏi bảo mật như "linh vật trung học của bạn là gì" chủ yếu là một dạng "điều gì đó bạn biết" tệ hại, hầu hết chúng đều dễ đoán hoặc hoàn toàn trong phạm vi công cộng.

Như bạn đã lưu ý, điều chỉnh lại các nỗ lực đăng nhập thất bại là một sự đánh đổi giữa việc ngăn chặn các cuộc tấn công vũ phu và dễ dàng thực hiện một tài khoản. Các chính sách khóa mạnh mẽ có thể phản ánh sự thiếu tự tin về entropy mật khẩu.

Cá nhân tôi không thấy lợi ích của việc thực thi hết hạn mật khẩu trên một trang web. Attacker lấy mật khẩu của bạn một lần, anh ta có thể thay đổi mật khẩu đó và tuân thủ chính sách đó một cách dễ dàng nhất có thể. Có lẽ một lợi ích là người dùng có thể nhận thấy sớm hơn nếu kẻ tấn công thay đổi mật khẩu tài khoản. Thậm chí sẽ tốt hơn nếu người dùng được thông báo bằng cách nào đó trước khi kẻ tấn công có được quyền truy cập. Các thông báo như "N lần thử thất bại kể từ lần đăng nhập cuối cùng" rất hữu ích về mặt này.

Bảo mật tốt nhất đến từ yếu tố xác thực thứ hai nằm ngoài băng tần so với yếu tố thứ nhất. Giống như bạn đã nói, mã thông báo phần cứng trong "thứ gì đó bạn có" rất tuyệt, nhưng nhiều (không phải tất cả) có chi phí quản trị viên thực sự liên quan đến phân phối của họ. Tôi không biết bất kỳ giải pháp sinh trắc học "gì đó là bạn" cho các trang web. Một số giải pháp hai yếu tố hoạt động với các nhà cung cấp openid, một số có SDK PHP / Perl / Python.

Đề xuất cao nhất của tôi là chỉ cần đảm bảo rằng bạn thông báo cho người dùng về những lần đăng nhập xấu vào tài khoản của họ-- Người dùng có thể sẽ coi trọng mật khẩu của họ hơn nếu họ đưa ra bằng chứng cho thấy ai đó thực sự đang cố xâm nhập vào tài khoản của họ .

Tôi thực sự bắt được ai đó đã xâm nhập vào tài khoản myspace của anh tôi vì họ đã cố xâm nhập vào tài khoản gmail mà tôi đã thiết lập cho anh ta và sử dụng tính năng 'đặt lại mật khẩu của tôi bằng email' ... đi vào hộp thư đến của tôi.

1. Điều gì về việc yêu cầu mật khẩu một lần trước khi nhập mật khẩu bình thường của họ? Điều đó sẽ làm cho rất rõ ràng rằng ai đó đã tấn công trước khi họ có nhiều cơ hội để đoán mật khẩu chính?

2. Giữ số lượng / tỷ lệ thất bại đăng nhập toàn cầu - đây là chỉ báo cho một cuộc tấn công - trong một cuộc tấn công nghiêm ngặt hơn về các lỗi đăng nhập, ví dụ như cấm IP nhanh hơn.

Tôi không tin có một câu trả lời hoàn hảo nhưng tôi sẽ có khuynh hướng tiếp cận nó trên cơ sở cố gắng làm bối rối các robot nếu một cuộc tấn công được cảm nhận.

Ngoài tâm trí tôi:

Chuyển sang một màn hình đăng nhập thay thế. Nó có nhiều khoảng trống tên người dùng và mật khẩu thực sự xuất hiện nhưng chỉ một trong số đó ở đúng nơi. Tên trường là RANDOM - một khóa phiên được gửi cùng với màn hình đăng nhập, sau đó máy chủ có thể tìm ra các trường là gì. Thành công hoặc thất bại sau đó bị loại bỏ để bạn không thể thử tấn công lại - nếu bạn từ chối mật khẩu, họ sẽ nhận được ID phiên mới.

Bất kỳ hình thức nào được gửi với dữ liệu trong một trường sai được cho là từ robot - đăng nhập thất bại, thời gian và IP đó được điều chỉnh. Đảm bảo tên trường ngẫu nhiên không bao giờ khớp với tên trường hợp pháp để ai đó sử dụng tên nhớ mật khẩu không bị đánh lừa.

Tiếp theo, về một loại hình xác thực khác: Bạn có một loạt câu hỏi sẽ không gây ra vấn đề gì cho con người. Tuy nhiên, chúng KHÔNG phải là ngẫu nhiên. Khi cuộc tấn công bắt đầu, mọi người được đưa ra câu hỏi số 1. Sau một giờ câu hỏi số 1 bị loại bỏ, không bao giờ được sử dụng lại và mọi người đều nhận được câu hỏi số 2, v.v.

Kẻ tấn công không thể thăm dò để tải xuống cơ sở dữ liệu để đưa vào robot của mình vì bản chất của các câu hỏi. Anh ta phải gửi hướng dẫn mới ra botnet của mình trong vòng một giờ để có khả năng làm bất cứ điều gì.

Vì một số người bao gồm CAPTCHA như một cơ chế dự phòng của con người, tôi đang thêm một câu hỏi và chủ đề về StackOverflow trước đó về hiệu quả của CAPTCHA.

ReCaptcha đã bị bẻ khóa / hack / OCR'd / bị đánh bại / bị hỏng chưa?

Sử dụng CAPTCHA không giới hạn các cải tiến từ điều chỉnh của bạn và các đề xuất khác, nhưng tôi nghĩ rằng số câu trả lời bao gồm CAPTCHA như một dự phòng nên xem xét các phương pháp dựa trên con người có sẵn cho những người muốn phá vỡ bảo mật.

Bạn cũng có thể điều tiết dựa trên độ mạnh của mật khẩu người dùng.

Khi người dùng đăng ký hoặc thay đổi mật khẩu của họ, bạn tính toán mức độ mạnh cho mật khẩu của họ, giả sử trong khoảng từ 1 đến 10.

Một cái gì đó như "mật khẩu" đạt điểm 1 trong khi "c6eqapRepe7et * Awr @ ch" có thể đạt điểm 9 hoặc 10 và điểm càng cao thì càng mất nhiều thời gian để điều tiết để đá vào.

Câu trả lời đầu tiên tôi thường nghe khi đặt câu hỏi này là thay đổi cổng, nhưng hãy quên điều đó đi và chỉ vô hiệu hóa IPv4. Nếu bạn chỉ cho phép khách hàng từ các mạng IPv6, bạn sẽ không còn cầu nguyện cho việc quét mạng đơn giản và những kẻ tấn công sẽ dùng đến việc tra cứu DNS. Đừng chạy trên cùng một địa chỉ với Apache (AAAA) / Sendmail (MX-> AAAA) của bạn / những gì bạn đã đưa ra cho mọi người (AAAA). Hãy chắc chắn rằng khu vực của bạn không thể xferd, chờ bạn cho phép khu vực của bạn được tải xuống bởi bất kỳ ai?

Nếu các bot tìm thấy máy chủ của bạn thiết lập tên máy chủ mới, chỉ cần thêm một số từ vô nghĩa vào tên máy chủ của bạn và thay đổi địa chỉ của bạn. Để lại tên cũ và thậm chí thiết lập ** tên honeypot cho mạng bot hết thời gian chờ.

** Kiểm tra các bản ghi đảo ngược (PTR) của bạn (dưới ip6.arpa.) Để xem liệu chúng có thể được sử dụng về 0 trong số 4 có bản ghi VS / 4s không. IE Thông thường ip6.arpa sẽ có ~ 32 "." Trong một địa chỉ nhưng cố gắng với một vài lần bị thiếu cuối cùng có thể trốn tránh các khối mạng có bản ghi VS khác không có. Nếu bạn đi xa hơn, có thể bỏ qua các phần lớn của không gian địa chỉ.

Trong trường hợp xấu nhất, người dùng sẽ phải thiết lập một đường hầm IPv6, không giống như họ phải đi xa tới VPN vào DMZ ... Mặc dù người ta tự hỏi tại sao đó không phải là lựa chọn đầu tiên.

Ngoài ra Kerberos rất tuyệt, nhưng IMHO LDAP thổi (Điều gì sai về mặt kỹ thuật với NISPlus? Tôi đã đọc rằng Sun đã quyết định rằng người dùng muốn LDAP và vì điều này họ đã bỏ NIS +). Kerberos hoạt động tốt mà không cần LDAP hoặc NIS, chỉ cần quản lý người dùng trên máy chủ theo cơ sở máy chủ. Sử dụng Kerberos giúp bạn dễ sử dụng, nếu không tự động, PKI.

Bit ở đây muộn nhưng tôi đã suy nghĩ, giả sử một trường hợp khó khăn - kẻ tấn công sử dụng rất nhiều IP ngẫu nhiên, tên người dùng ngẫu nhiên và mật khẩu ngẫu nhiên được chọn từ danh sách 10.000 phổ biến nhất.

Một điều bạn có thể làm, đặc biệt là nếu hệ thống dường như bị tấn công trong đó có rất nhiều lần thử mật khẩu sai trên hệ thống và đặc biệt là nếu mật khẩu có entropy thấp là hỏi một câu hỏi phụ như tên của bố mẹ bạn là gì, chẳng hạn . Nếu kẻ tấn công tấn công một triệu tài khoản đang thử mật khẩu 'password1', rất có thể họ sẽ nhận được rất nhiều nhưng khả năng họ nhận được tên đúng sẽ làm giảm đáng kể thành công.