Đăng nhập tên miền chéo - Cách đăng nhập người dùng tự động khi được chuyển từ miền này sang miền khác

Question

Chúng tôi cung cấp một số dịch vụ trực tuyến. Chúng tôi bắt buộc phải phát triển một hệ thống cung cấp trải nghiệm nhanh/đơn giản cho người dùng nếu họ được chuyển từ một dịch vụ (trên domain1.com) sang một dịch vụ khác (trên domain2.com).

Có cách nào an toàn và bảo mật để tự động đăng nhập người dùng một cách tự động sau khi anh ấy được chuyển sang dịch vụ mới không?

Nói với tôi nếu giải pháp dưới đây hoàn toàn không an toàn/sai.

Chúng tôi đang xem xét một hệ thống tương tự như một số dịch vụ trực tuyến để khôi phục mật khẩu - chúng được gửi qua email liên kết có mã băm duy nhất hết hạn, cho phép họ thay đổi mật khẩu của họ.

domain1.com sẽ tạo một băm duy nhất và lưu nó vào cơ sở dữ liệu với băm được liên kết với người dùng cùng với trường ngày hết hạn.

Người dùng sẽ được chuyển giao cho domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com tiếp theo sẽ làm cho một yêu cầu đến domain1.com với băm để có được những thông tin về người dùng. domain1.com sau đó sẽ loại bỏ băm từ cơ sở dữ liệu. domain2.com sẽ đăng nhập người dùng và đặt cookie, v.v.

Có thể dựa trên OpenID hoặc OAuth kết quả tương tự không?

Answer 1

Nếu ai đó có thể chơi đàn ông ở giữa và lấy băm đó, họ có thể ăn cắp chuyển tên miền chéo không? Rõ ràng nó cần phải được tạo ra và gửi cho khách hàng trước khi họ cần phải sử dụng nó. Vì vậy, ví dụ:

Tôi đang chơi đàn ông đang gián điệp trên Jack. Jack truy cập domain1.com gây ra một băm được chuẩn bị và gửi cho anh ta để khi anh truy cập domain2.com anh ta có thể gửi băm đó làm xác thực. Khi ông truy cập domain1.com, yêu cầu của ông đến thông qua tôi, bạn quay trở lại trang, tôi lấy băm và để anh ta tiếp tục. Tôi truy cập domain2.com bằng cách sử dụng hàm băm, bây giờ bạn đã cho phép tôi vào domain2.com và xóa băm. Anh ấy không khôn ngoan hơn cho đến khi anh ta cố đăng nhập vào domain2.com và được thông báo rằng thông tin đăng nhập của anh ấy không còn hợp lệ nữa.

Làm thế nào để bạn vượt qua điều đó?

Answer 2

Đây là giải pháp tốt. Dưới đây là hai điểm cần xem xét:

Bạn sử dụng thuật ngữ "băm", nhưng không rõ dữ liệu nào bạn sẽ băm. Thay vào đó, sử dụng một "nonce": một số lớn (128-bit) được tạo ra bởi một RNG chất lượng mật mã.

Ngoài ra, bạn không chỉ định điều này, nhưng thông tin liên lạc giữa người dùng và cả tên miền và giữa các tên miền, phải được bảo mật. Sử dụng SSL để xác thực máy chủ và giữ bí mật thông tin.

Answer 3

Đăng nhập một lần (SSO) là khái niệm khá đơn giản.

• Lượt truy cập của người dùng domain1.com.
• domain1.com thấy không có cookie phiên.
• domain1.com chuyển hướng đến sso.com
• sso.com trình bày trang đăng nhập, và lấy thông tin
• sso.com bộ phiên cookie cho người dùng
• sso.com sau đó chuyển hướng trở lại domain1 đến một url đặc biệt (như domain1.com/ssologin)
• các ssologin URL chứa thông số về cơ bản là "đã ký" bởi sso.com. Nó có thể đơn giản như một base64 mã hóa loginid bằng cách sử dụng khóa bí mật được chia sẻ.
• domain1.com lấy mã thông báo được mã hóa, giải mã mã thông báo, sử dụng id đăng nhập mới để đăng nhập vào người dùng.
• domain1 đặt cookie phiên cho người dùng.

Hiện tại, trường hợp tiếp theo.

• tài chạm domain2.com, mà sau domain1 và chuyển hướng đến sso.com
• sso.com đã có một cookie cho người sử dụng, vì vậy không trình bày các trang đăng nhập
• sso.com chuyển hướng trở lại domain2.com với các thông tin được mã hóa
• domain2.com nhật ký trong người dùng.

Đó là nguyên tắc cơ bản về cách hoạt động của tính năng này. Bạn có thể làm cho nó mạnh mẽ hơn, giàu tính năng hơn (ví dụ: đây là SSOn, nhưng không phải SSOff, người dùng có thể "đăng xuất" domain1 nhưng vẫn đăng nhập vào domain2). Bạn có thể sử dụng khóa công khai để ký thông tin đăng nhập, bạn có thể có yêu cầu chuyển thêm thông tin (như quyền ủy quyền, v.v.) từ máy chủ SSO. Bạn có thể tích hợp thân mật hơn, chẳng hạn như các miền thường xuyên kiểm tra xem người dùng vẫn có quyền từ máy chủ SSO hay không.

Nhưng bắt tay cookie thông qua trình duyệt bằng cách sử dụng chuyển hướng là nền tảng quan trọng mà tất cả các giải pháp SSO này dựa vào.

Answer 4

Điều gì về SEO? Dường như mọi yêu cầu trước khi đăng nhập thành công được chuyển hướng đến miền khác và ngược lại. Tôi sẽ nói rằng điều này rất xấu. Bạn nên gửi tiêu đề nào? 301 đến SSO và sau đó quay lại 301 về trang gốc? Vì vậy, tìm kiếm bot là "yêu cầu" để thay đổi chỉ số của mình cho trang đó hai lần?

Answer 5

Sẽ không có bất kỳ điểm nào sử dụng SSL cho thông tin đăng nhập tên miền chéo trừ khi bạn sử dụng SSL cho toàn bộ phiên. Nó chỉ là dễ dàng để ăn cắp một cookie phiên vì nó là sử dụng một băm trong một url. Điểm ẩn trong băm trong SSL là gì nếu phần còn lại của phiên không an toàn.

Phương pháp được đưa ra ở trên cùng là phương pháp chuẩn. Cho dù bạn chọn sử dụng giao thức bảo mật thì hoàn toàn là vấn đề khác, nhưng sẽ vô nghĩa khi chỉ mã hóa một phần của phiên.