Điểm yếu của Bảo mật 3-Strike


10

Tôi đã đọc một số tài liệu về bảo mật, cụ thể là bảo mật / mã hóa mật khẩu, và có một điều mà tôi đã tự hỏi: quy tắc 3 lần là một giải pháp hoàn hảo để bảo mật mật khẩu? Đó là, nếu số lần thử mật khẩu bị giới hạn ở một số lượng nhỏ, sau đó tất cả các yêu cầu xác thực sẽ không được thực hiện, điều đó có bảo vệ người dùng khỏi sự xâm nhập không? Tôi nhận thấy việc có quyền truy cập hoặc kiểm soát đối với một cái gì đó không phải lúc nào cũng có nghĩa là thông qua hệ thống xác thực, nhưng tính năng này không làm cho các cuộc tấn công từ điển / vũ phu trở nên lỗi thời? Có thiếu điều gì không?


3
Câu hỏi này có thể đã được hỏi tốt hơn tại Security để tham khảo trong tương lai.
maple_shaft

1
Như tôi đã tìm thấy, luôn có một nơi nào đó thích hợp hơn để hỏi. Dù vậy, cảm ơn, tôi sẽ cố gắng và nhớ điều đó.
prelic

Câu trả lời:


13

Có, nó sẽ làm cho các cuộc tấn công từ điển không thể thông qua cơ chế đăng nhập . (Tuy nhiên, điều đó không có nghĩa gì nhiều nếu họ có quyền truy cập vào cơ sở dữ liệu. Để bảo mật, bạn sẽ cần phải băm và muối đúng mật khẩu.)

Nó cũng cho phép khả năng tấn công DOS vào một người dùng nhất định. Giả sử tôi muốn ngăn bạn đăng nhập. Tất cả những gì tôi phải làm là chạy ba lần đăng nhập không có thật vào tài khoản của bạn và sau đó làm lại mỗi khi bạn làm bất cứ điều gì cần thiết để đặt lại đăng nhập. Đối phó với vấn đề đó là một chút phức tạp hơn.


1
Cảm ơn! Vì tò mò, đâu sẽ là một cách tiếp cận để đối phó với vấn đề sau mà bạn mô tả? Đối với một ví dụ trong thế giới thực, hàng tấn diễn đàn trực tuyến sử dụng tên người dùng công khai làm id đăng nhập (trái ngược với email được đính kèm với acct hoặc một cái gì đó khác), có nghĩa là tôi có thể thấy mọi người dùng đang sử dụng để đăng nhập. Điều gì để ngăn tôi khóa mọi người dùng khỏi tài khoản của họ? Một quản trị viên tốt? Có vẻ như sẽ rất dễ dàng để khóa mọi người dùng ra khỏi trang web.
prelic

@prelic: Chà, để giải quyết vấn đề đó, tôi sẽ triển khai một cái gì đó như "nếu một địa chỉ IP nào đó thực hiện quá nhiều lần thử đăng nhập không hợp lệ, hãy chặn chúng." Điều đó sẽ ngăn chặn kịch bản bạn đã đề cập, nhưng nó sẽ không đối phó với một nỗ lực hack nghiêm trọng như botnet. Cho rằng bạn cần bảo mật nặng hơn.
Mason Wheeler

4
Giải pháp thông thường là ràng buộc tốc độ cố gắng của một người dùng nhất định từ một ip cố định để nói 5 mỗi phút. Nó không hoàn hảo nhưng thường thì bạn không tạo ra vấn đề cho những người dùng khác, trừ khi bạn đứng sau cùng một proxy
Andrea

Một cách tiếp cận khác là trình bày một captcha sau 2 lần đăng nhập thất bại từ cùng một IP - nhưng sau đó, một kẻ tấn công quyết tâm chỉ có thể thuê một chiếc máy cơ phá vỡ captcha cho mục đích này, cộng với rất khó để tìm thấy một captcha tốt thực sự giữ máy ngoài.
tdammers

3

Tôi cũng đồng ý rằng nó làm cho các cuộc tấn công từ điển kém hiệu quả hơn như là cách để có quyền truy cập vào tài khoản mà không có thẩm quyền thích hợp. Tuy nhiên:

  • Cách tiếp cận này có thể biến một cuộc tấn công từ điển thành một cuộc tấn công DOS chống lại hệ thống ngăn chặn truy cập nếu được thực hiện kém. Ví dụ, một máy chủ có thể bị ngập trong các nỗ lực xác thực. Một cách khác là để dịch vụ xác thực kiểm soát luồng truy cập tiếp theo vào tài khoản bị khóa. Ví dụ: nếu tài khoản bị khóa, hãy trình bày độ trễ trước mỗi lần đăng nhập tiếp theo. Tuy nhiên, người ta có thể đặt độ trễ giữa lần thử đăng nhập và 'quyền truy cập bị từ chối', tuy nhiên, điều đó giúp mở cửa cho một cuộc tấn công từ chối dịch vụ phân tán, nơi kẻ tấn công khởi chạy nhiều lần xác thực đồng thời.

  • Như đã đề cập trong câu trả lời khác, điều này cũng có thể biến một cuộc tấn công từ điển thành một DOS thô sơ chống lại chủ sở hữu hợp pháp của tài khoản bị tấn công. Các cách để giảm thiểu tác động đến chủ sở hữu hợp pháp bao gồm:

    • Làm chậm quá trình chạy tên người dùng bằng cách không cung cấp manh mối về việc đó là tên người dùng hoặc mật khẩu sai. Điều này làm cho các cuộc tấn công mà thủ phạm đoán tên người dùng dễ thấy hơn đối với các quản trị viên và kém hiệu quả hơn.
    • Thay vì khóa tài khoản sau một số lần thử thất bại cố định, chỉ cần khóa chế độ xác thực đó. Nói cách khác, yêu cầu người dùng đang bị tấn công để xác thực bằng cách sử dụng một phương thức khác (có thể liên quan nhiều hơn, nhưng ít bị tấn công hơn). Một ví dụ điển hình là cách điện thoại Android sẽ yêu cầu người dùng sử dụng thông tin Đăng nhập Google của họ sau khi không xác thực bằng cách sử dụng mẫu mở khóa màn hình hoặc mã PIN. Về lý thuyết, đây là loại giống như yêu cầu người dùng bị tấn công yêu cầu mở khóa tài khoản của họ, tuy nhiên, nó không yêu cầu sự can thiệp ngay lập tức từ quản trị viên hệ thống.
    • Thay vì khóa tài khoản (hoặc ngoài việc khóa tài khoản, đối với chế độ xác thực cụ thể này - xem ở trên), hãy khóa các nỗ lực để xác thực từ vị trí nơi cuộc tấn công bắt nguồn. Ví dụ: nếu xác thực được thực hiện thông qua tên người dùng và mật khẩu, qua mạng, sau ba lần xác thực không thành công, bạn có thể ngăn người dùng khác từ cùng một IP hoặc mạng con đăng nhập bằng tên người dùng hoặc mật khẩu. Khi có nhiều khả năng nhiều người dùng (bao gồm cả kẻ tấn công) có thể sử dụng cùng một IP hoặc mạng con, bạn chỉ có thể vô hiệu hóa xác thực tên người dùng / mật khẩu cho IP hoặc mạng con trong một khoảng thời gian, để lại nhiều phương thức xác thực liên quan mở cho vô tội người dùng ở gần kẻ tấn công.
  • Nếu nỗi sợ của bạn vô tình phạt một người dùng hay quên như thể họ là kẻ tấn công, thay vì kiểm soát luồng nỗ lực đăng nhập thất bại sau một số lần thử thất bại cố định, bạn có thể sử dụng tần suất đăng nhập cố định làm bằng chứng tài khoản bị tấn công. Ví dụ: nếu bạn thấy 10 lần thử xác thực trong khoảng thời gian một giây, bạn có thể sử dụng một trong các phương pháp ở trên để ngăn các lần thử xác thực tương tự tiếp theo. Thay phiên, bạn có thể sử dụng cơn lũ đăng nhập nhanh chóng này như một tín hiệu để bắt đầu kiểm soát dòng chảy. Phương pháp này ngày càng trở nên phổ biến trên các diễn đàn, trong khi đó, sau một số lần thử đăng nhập thất bại từ một IP cụ thể, IP đó bị ngăn không thể xác thực trong một khoảng thời gian ngắn.

  • Cuối cùng, một cách tốt để ngăn người dùng liên tục bị tấn công bởi DOS là bằng cách cho phép anh ta / cô ta đặt lại cả mật khẩu và tên người dùng của mình . Nói cách khác, coi cả tên người dùng và mật khẩu là bí mật. Trường hợp tên người dùng được sử dụng ở nơi khác (ví dụ: trong diễn đàn, nếu tên người dùng là tên hiển thị của người dùng), chỉ cần coi tên hiển thị này là một tên riêng biệt. Cách tiếp cận này thường được sử dụng bởi các mạng xã hội nơi tên người dùng được sử dụng để xác thực là địa chỉ email của một người - một cái gì đó có thể thay đổi, nhưng hiếm khi được chia sẻ - trong khi tên hiển thị được sử dụng trên trang web là tên do người dùng xác định có thể có hoặc không bị thay đổi.

Dù sao, tôi hy vọng một hoặc một số kết hợp của các phương pháp này sẽ có ích.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.