Các lỗ hổng bảo mật của OAuth và lừa đảo, chúng có thể gắn liền với nhau không?

Question

Gần đây tôi đã làm một chút công việc với OAuth và tôi phải nói rằng tôi thực sự thích nó. Tôi thích khái niệm này và tôi thích cách nó cung cấp rào cản thấp cho người dùng của bạn để kết nối dữ liệu ngoài với trang web của bạn (hoặc để bạn cung cấp apis dữ liệu để sử dụng bên ngoài). Cá nhân, tôi đã luôn luôn balked tại các trang web mà yêu cầu tôi để cung cấp đăng nhập của tôi cho một trang web cho họ trực tiếp. Và OAuth "valet key cho web" phương pháp tiếp cận giải quyết điều này độc đáo.

Vấn đề lớn nhất mà tôi (và nhiều người khác) gặp phải là luồng công việc OAuth tiêu chuẩn khuyến khích cùng loại hành vi mà các cuộc tấn công lừa đảo sử dụng lợi thế của họ. Nếu bạn đào tạo người dùng của mình rằng hành vi bình thường sẽ được chuyển hướng đến trang web để cung cấp bằng chứng xác thực đăng nhập thì sẽ dễ dàng cho trang web lừa đảo khai thác hành vi bình thường đó mà thay vào đó chuyển hướng đến trang web nhân bản của họ nơi họ chụp tên người dùng và mật khẩu của bạn.

Điều gì, nếu có, bạn đã làm (hoặc đã xem xong) để giảm bớt vấn đề này?

• Bạn có yêu cầu người dùng truy cập và đăng nhập vào trang cung cấp theo cách thủ công, không có liên kết hoặc chuyển hướng tự động không? (nhưng sau đó điều này làm tăng rào cản nhập cảnh)

• Bạn có cố gắng giáo dục người dùng của mình và nếu có, khi nào và như thế nào? Bất kỳ lời giải thích lâu dài về bảo mật mà người dùng phải đọc cũng làm tăng rào cản nhập cảnh.

Còn gì nữa?

Answer 1

Để mở rộng tương tự dịch vụ đỗ xe: làm cách nào bạn biết bạn có thể tin cậy người hầu và rằng họ không chỉ là người đang cố gắng? Bạn không thực sự: bạn chỉ làm điều đó (có lẽ vô ý thức) dựa trên ngữ cảnh: bạn biết khách sạn, bạn đã từng ở đó, thậm chí bạn có thể nhận ra người mà bạn đang đưa chìa khóa của mình.

Trong cùng một cách, khi bạn đăng nhập bằng OAuth (hoặc OpenID), bạn đang chuyển hướng người dùng đến trang web/URL nên quen thuộc với họ, khi họ cung cấp thông tin xác thực từ trang web đó đối với họ.

Answer 2

Tôi tin rằng OAU và lừa đảo chúng không thể liên kết được, ít nhất là ở dạng hiện tại của OAuth. Đã có các hệ thống để ngăn chặn lừa đảo, hầu hết các HTTP đáng chú ý (tạm dừng cho tiếng cười ...), nhưng rõ ràng là nó không hoạt động.

Lừa đảo là một cuộc tấn công rất thành công đối với các hệ thống yêu cầu combo tên người dùng/mật khẩu. Miễn là mọi người sử dụng tên người dùng và mật khẩu để xác thực lừa đảo sẽ luôn là một vấn đề. Một hệ thống tốt hơn là sử dụng mật mã không đối xứng để xác thực. Tất cả các trình duyệt hiện đại đều hỗ trợ thẻ thông minh. Bạn không thể phish một thẻ ngồi trong ví ai đó và hack máy tính để bàn của người dùng sẽ không bị rò rỉ khóa riêng. Cặp khóa không đối xứng không nhất thiết phải là một thẻ thông minh, nhưng tôi nghĩ rằng nó xây dựng một hệ thống mạnh hơn nếu nó được thực hiện hoàn toàn trong phần mềm.

Answer 3

Đây không chỉ là vấn đề OAuth, đó cũng là vấn đề của OpenID. Tồi tệ hơn tất nhiên với OpenID bạn đang cung cấp một trang web cho nhà cung cấp của bạn, thật dễ dàng để tự động xóa trang web đó nếu bạn không có trang giả mạo và tạo một trang mà sau đó bạn hướng người dùng của bạn.

Thật may là không có gì nghiêm trọng khi sử dụng OpenID để xác thực - bài đăng trên blog, nhận xét flickr không phải là mục tiêu hấp dẫn.

Bây giờ OpenID sẽ giảm bớt khi họ bắt đầu phát triển hỗ trợ Thẻ thông tin của họ, nơi một giao diện người dùng cố định trong hình dạng phần mềm phía máy khách sẽ cung cấp danh tính "ví" an toàn, nhưng MS dường như đã giảm tự đánh bóng trên thẻ thông tin, mặc dù đó là thông số kỹ thuật (mở) của họ.

Nó sẽ không biến mất bất cứ lúc nào sớm.

Answer 4

Điều gì về việc chứng nhận nhà cung cấp oAuth giống như chứng nhận ssl? Chỉ nhà cung cấp oAuth được chứng nhận mới đáng tin cậy. Nhưng vấn đề là, như với chứng nhận ssl, các vấn đề CA.

Answer 5

Bạn có một tài khoản với trang web mà bạn đang được chuyển hướng đến, họ có nên triển khai các biện pháp chống lừa đảo như cụm từ chữ ký và hình ảnh không? Điều này cũng thúc đẩy mọi đào tạo hiện có mà người dùng đã nhận được từ ví dụ: các ngân hàng thường sử dụng các biện pháp này.

Nói chung, trang đăng nhập phải hiển thị bí mật được chia sẻ thân thiện với người dùng cho người dùng để xác nhận danh tính của trang web họ đang đăng nhập. Khi ghi chú Jingle, chứng chỉ ssl có thể được sử dụng để xác thực, nhưng trong trường hợp này người dùng không thể tải chứng chỉ trực tiếp từ trang web vào trình duyệt web của họ như một phần của quy trình thiết lập OAuth? Nếu mối quan hệ tin cậy đã được thiết lập với trang web, tôi không chắc chắn phải tiếp tục sử dụng CA nữa.

Answer 6

Có một số kỹ thuật có thể được sử dụng để tránh hoặc giảm bớt các cuộc tấn công lừa đảo. Tôi đã tạo danh sách các tùy chọn giá rẻ:

1. Tài nguyên nhận dạng lẫn nhau. E.x. biểu tượng được liên kết với một người dùng cụ thể chỉ hiển thị sau khi người dùng nhập tên người dùng của mình.
2. Sử dụng tên người dùng không xác định và tránh email làm tên người dùng.
3. Bao gồm tùy chọn để người dùng xem lịch sử đăng nhập của anh ấy.
4. Mã QR cho phép xác thực trong thiết bị được đăng ký trước như điện thoại thông minh. Giống như trang web WhatsApp.
5. Hiển thị số xác thực trong các trang đăng nhập mà người dùng có thể xác thực trong trang web chính thức của công ty.

Tất cả các tùy chọn được liệt kê ở trên đều phụ thuộc vào giáo dục người dùng về bảo mật thông tin và quyền riêng tư. Các trình thủ thuật xuất hiện chỉ trên xác thực đầu tiên có thể giúp đạt được mục tiêu này.