通过域安全地通过HTTP发送数据

Question

I'm developing an SSO solution where there is one master authentication site and multiple slave sites. I'm at the point where when someone registers on a slave it needs to forward the registration to the master and consequently log the user in to the master as well.

There's MANY ways of going about this, currently I'm planning to encrypt the needed registration /login data and redirecting the end-user with this data in a hidden iframe, so that the end-user is not bothered by this process (this will be covered in the sites T&C's). Now it's already using SSL but I want to make this process as secure as possible. Currently I'm encrypting the data send with a key that the master and slaves both hold in their configuration. I'm worried though that someone might be able to crack this as the key is always the same, and am thinking of using a salt along with that key that the master will have to obtain from the slave for each individual query, but this doubles the amount of HTTP queries needed.

I'm simply wondering whether I'm overthinking this, or if I'm being too cautious (after all, SSL alone should theoretically be sufficient).

Any advice? Thanks

Answer 1

In most cases, SSL should be sufficient. If the server's certificate and private key are stored securely, certificate revocation is checked regularly, the private key is not weak (and so on...), the channel between the end user's browser and your server (as well as the one between the master and the slave sites) will be protected from eavesdropping, preventing others from seeing the credentials.

What SSL does not do is authenticating the "client" side of the connection, that is, anyone knowing the right URLs could connect, authenticate (impersonating a slave site) and obtaining an authentication/login token (if the supplied credentials are correct). This implies that, given a token, your master server would only not be able to discriminate which site is performing "privileged" functions. The credentials themselves would remain protected by SSL, and the attacker would still need to know them to perform the attack. (I have assumed there are no other bugs in the sites themselves, like XSS vulnerabilities or incorrect cookie management).

That said, you should use a key (or a secret in form of a string) and pass it from the slave sites to the master one only if you need to manage permissions inside this network at a great level of detail (like preventing login on certain sites and allowing it on others based on the user's identity, or temporarily deny logins to certain sites if some of them are not under your direct control and you suspect compromise); if that's the case, I suggest you take a look at the OAuth site, it's a protocol designed exactly for that purpose (you could simply write an API that allows logins and retrieves necessary data from the master server).

If (and only if) all the sites are under your direct control, using just SSL should be enough; the burden to manage two sets of keys (one for SSL and one for additional encryption) would be too high, and the servers would use too much resources. Only make sure SSL is used between the browsers and the servers as well as for all communication between the servers themselves, to defend against network sniffing.