Có một phương pháp tiêu chuẩn để chứng minh bảo mật mật khẩu cho những người không phải là nhà toán học?

Khách hàng của tôi có một máy chủ đang phải chịu các nỗ lực đăng nhập vũ phu từ mạng botnet. Do sự mơ hồ của máy chủ và máy khách của khách hàng, chúng tôi không thể dễ dàng chặn các nỗ lực thông qua tường lửa, thay đổi cổng hoặc thay đổi tên tài khoản đăng nhập.

Quyết định đã được đưa ra để nó mở để tấn công, nhưng tìm một phương pháp giữ mật khẩu an toàn. Quản lý và một số chuyên gia tư vấn khác đã xác định rằng điều tốt nhất cần làm là cài đặt phần mềm xoay mật khẩu để xoay mật khẩu cứ sau mười phút và cung cấp mật khẩu mới cho người dùng cần đăng nhập.

Các nỗ lực vũ phu đang xảy ra hai lần mỗi giây.

Tôi cần chứng minh rằng việc thực hiện một mật khẩu mạnh với 12-15 ký tự là một giải pháp dễ dàng và miễn phí. Tôi biết cách chứng minh điều này bằng toán học, nhưng tôi chỉ viết một cái gì đó như "có x nhiều hoán vị có thể có của mật khẩu của chúng tôi và kẻ tấn công chỉ có thể thử n lần thử mỗi ngày, vì vậy chúng tôi hy vọng chúng sẽ đi x / Trung bình 2n ngày trước khi họ đoán mật khẩu của chúng tôi. " Có một "bằng chứng" tiêu chuẩn hơn về điều này?

Sử dụng fail2ban với iptables là một cách tuyệt vời.

Đây là toán học cho bạn:

Bảng chữ cái chữ thường và chữ thường và ký hiệu phổ biến, dài 8 ký tự, mang lại cho bạn 2,9 triệu triệu kết hợp và với 10.000 lần thử một giây sẽ mất 9,488 năm. Đó là mức tối đa của khóa học - hy vọng mật khẩu của bạn sẽ bị bẻ khóa trong 4000 năm. 1000 năm nếu bạn không cảm thấy may mắn.

Như bạn có thể thấy, bạn không nên có bất kỳ vấn đề gì nếu bạn thực hiện mật khẩu 15 ký tự như:

dJ&3${bs2ujc"qX

Ngoài fail2ban,

Nếu bạn đang chạy bất kỳ UNIX hiện đại nào, bạn thường có thể thay đổi thời gian ngủ của mật khẩu xấu thành tối đa 5 giây, làm chậm tốc độ tấn công 2000%. [Solaris 10 có nó trong / etc / default / login, tìm kiếm SLEEPTIME] Mà sử dụng cùng một dung sai có nghĩa là bạn có thể xoay mật khẩu cứ sau 3 giờ 20 phút.

Ngoài ra, mật khẩu thử trước khi khóa sẽ là một lựa chọn khả thi, nhưng tôi nghi ngờ nó không dành cho bạn vì bạn có nhiều người dùng chia sẻ một tài khoản và không muốn nó bị khóa mọi lúc.

Yêu cầu mật khẩu 12-15 ký tự sẽ giúp, nhưng nếu bạn liên tục bị tấn công thì một giải pháp khác có lẽ tốt hơn. Tôi không biết khả năng chịu ngân sách của công ty bạn về vấn đề này là gì, nhưng thẻ chìa khóa RSA cho mọi người cần đăng nhập vào tài khoản đó cũng sẽ giải quyết được. Xác thực hai yếu tố đẩy xác suất ra thời gian tính toán lượng tử.

Cách tiếp cận vũ phu diễn ra đủ lâu để bạn đăng lên bảng này là khá ngạc nhiên. Nói chung, nó khá thấp và tốt nhất là một bản ghi nhật ký trong khi một cuộc tấn công thực sự đang diễn ra.

Làm thế nào về một kháng cáo lên chính quyền? Bạn có thể tham khảo Nguyên tắc triển khai kỹ thuật bảo mật của DoD (iase.disa.mil/stigs/stig) và nói "Nếu nó đủ tốt cho Bộ Quốc phòng, thì nó đủ tốt cho chúng tôi"

Một điều cần xem xét: nếu bạn có mật khẩu không thay đổi và các cuộc tấn công vũ phu đang kiểm tra một vũ trụ mật khẩu bao gồm mật khẩu của bạn, thì cuộc tấn công vũ phu được đảm bảo sẽ tấn công và cuối cùng bạn sẽ dễ bị tổn thương.

"Cơ hội" mà một lựa chọn ngẫu nhiên sẽ đánh vào mật khẩu của bạn có thể được tính toán, như bạn đã đề xuất, nhưng điều đó có thể không nói lên toàn bộ câu chuyện.

Ví dụ, nếu bạn nhìn vào các nỗ lực vũ phu, và thấy rằng mật khẩu dài nhất họ thử là 10 ký tự, chọn bất cứ thứ gì ở 12 sẽ đảm bảo bạn sẽ không bao giờ bị đánh.

Hãy thật cẩn thận khi cố gắng áp dụng số liệu thống kê cho một trường hợp cụ thể; họ chỉ dự đoán hành vi tổng thể với một số lượng lớn các mẫu.

Điều đó sang một bên, nếu toán học không (hoặc không thể) thuyết phục được ai đó, hãy thử tìm thứ gì đó có cùng cơ hội xảy ra nhưng quen thuộc, như có lẽ là xổ số hoặc tai nạn xe hơi hoặc bị sét đánh. Nếu bạn có thể nói "cơ hội của một ai đó chạm này mật khẩu là về giống như trúng số sáu tuần chạy" nó có thể cung cấp cho họ một cảm giác tốt hơn.

Một điều chưa được xem xét là tên người dùng mà botnet đang sử dụng cho Bruteforce. Trong tất cả các trường hợp tôi đã thấy các lực lượng vũ phu là các biến thể của quản trị viên và root, và trong một trường hợp hiếm hoi tên người dùng được lấy từ trang web của corp.

Tôi cũng thay đổi các hạn chế đăng nhập tương tác để tài khoản gốc của bạn bị vô hiệu hóa (ưu tiên) hoặc bị giới hạn trong mạng con cục bộ hoặc phạm vi địa chỉ tương tự.

Hai lần mỗi giây không phải là xấu. Chúng tôi đã từng thấy hàng ngàn lần thử mỗi phút, trước khi triển khai fail2ban , việc này sẽ khóa một IP cụ thể ra khỏi mạng trong một khoảng thời gian sau nhiều lần thử thất bại (tất cả đều có thể định cấu hình).

Điều này đã làm việc rất tốt cho chúng tôi.

Trên thực tế, bạn có thể quét chọn lọc chống lại các cuộc tấn công ssh brute force bằng iptables, nếu điều này hiệu quả với bạn.

Hai chuỗi này:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name sshscans 
iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 5 --name sshscans --rsource -j DROP 

sẽ chặn quyền truy cập vào bất kỳ ai cố gắng kết nối với SSH hơn 5 lần trong khoảng thời gian 60 giây. Bạn có thể thay đổi số "- số đếm" nếu bạn muốn số lớn hơn 5 mỗi giây được cho phép.

Tôi đồng ý rằng việc thay đổi mật khẩu cứ sau 10 phút có vẻ hơi quá. Tại thời điểm này, vấn đề trở thành làm thế nào để bạn truyền mật khẩu mới một cách an toàn và giữ cho các hệ thống đồng bộ với nhau.

Bài viết này có một số thống kê thú vị về tốc độ bẻ khóa:

http://www.lockdown.co.uk/?pg=combi

http://en.wikipedia.org/wiki/Password_cracking

Thật đáng ngạc nhiên khi nhiều người không hiểu các đường cong theo cấp số nhân, nhưng mọi người đều biết sự khác biệt giữa 10, 100 và 1000, vì vậy đó có thể là một nơi tốt để bắt đầu so sánh.

Một chiến thuật khác có thể là thực sự cho mọi người thấy phải mất bao lâu để bắt bẻ mật khẩu 6 ký tự. Nếu bạn có bất kỳ kiến ​​thức lập trình nào, bạn có thể kết hợp một công cụ nhanh chóng thực hiện việc này.

Bạn cũng có thể cho họ thấy các bảng cầu vồng có sẵn dễ dàng như thế nào:

http://project-rainbowcrack.com/table.htm

Điều này có thể hơi bất thường, nhưng tôi đang sử dụng denyhost và nó đã giảm đáng kể các nỗ lực vũ phu trên các hộp Linux của tôi.