我正在开发一个SSO解决方案，其中有一个主身份验证站点和多个从站点。当有人在奴隶上注册时，我需要将注册转发给主人，然后将用户登录到主人。
有很多方法可以解决这个问题，目前我正在计划加密所需的注册/登录数据，并将最终用户重定向到隐藏的iframe中的这些数据，以便最终用户不会受到此过程的困扰（这将在T＆amp; C的网站上介绍）。现在它已经在使用SSL，但我想让这个过程尽可能安全。目前我正在用主密钥和从属密钥在其配置中保存的密钥加密数据发送。我担心虽然有人可能会破解这个，因为密钥总是一样的，并且我正在考虑使用一个盐以及主密钥必须从每个查询的从服务器获取的密钥，但这会增加一倍需要的HTTP查询量。
我只是想知道我是否过度思考这一点，或者我是否过于谨慎（毕竟，理论上理论上只有SSL就足够了）。
有什么建议吗？感谢
答案 0 :(得分：2)
在大多数情况下，SSL应该足够了。如果安全地存储服务器的证书和私钥，则定期检查证书撤销，私钥不弱（等等......），最终用户的浏览器和服务器之间的通道（以及之间的通道）将保护主站点和从站点免受窃听，防止其他人看到凭据。
SSL不做的是验证连接的“客户端”端，即知道正确的URL可以连接，验证（模拟从站点）和获取身份验证/登录令牌的任何人（ if < / em>提供的凭据是正确的）。这意味着，给定令牌，您的主服务器将无法区分哪个站点正在执行“特权”功能。凭证本身仍然受SSL保护，攻击者仍然需要知道它们才能执行攻击。 （我假设网站本身没有其他错误，例如XSS漏洞或错误的cookie管理）。
那就是说，你应该使用一个密钥（或一个字符串形式的秘密），如果你需要在这个网络内部管理权限，那么将它从从属站点传递给主站点 。一个很好的细节（例如阻止在某些网站上登录，并根据用户的身份在其他网站上允许登录，或暂时拒绝登录某些网站，如果其中一些网站不在您的直接控制之下并且您怀疑妥协）;如果是这种情况，我建议你看看OAuth site，这是一个专门为此目的设计的协议（你可以简单地编写一个允许登录并从主服务器检索必要数据的API）。
如果（且仅当）所有网站都在您的直接控制之下，仅使用SSL就足够了;管理两组密钥（一个用于SSL，一个用于额外加密）的负担太高，服务器将使用太多资源。只确保在浏览器和服务器之间使用SSL以及服务器本身之间的所有通信，以防止网络嗅探。