Authentication concept for sites served to another site

Question

We are going to serve content to a Content Management System that embeds it through an iframe (yuck). Some pages that we serve need to be authenticated before – only a valid user should be able to see them.

The company who previously implemented what we're about to do did this through the requests. Of course, since there was no session management. The use of iframes kinda made it impossible to use cookies, etc. This is no real authentication, but that's what they did…

http://example.com/get.php?ID=1234&[email protected]

Believe it or not: One could easily get the content of another user by exchanging ID or e-mail. Now we want (or, have) to change that. The problem is that we do not have access to the customer data. We don't know e-mail address and user IDs of the CMS.

The initial plan that had been developed was to send us a salted hash with e-mail and ID, and somebody thought it was possible to extract e-mail and ID from the hash again if we knew the salt. Well, turns out they didn't know how hashes work… so it's on me to come up with something new.

Here is the first scenario I thought of:

In this case we only receive a list of valid hashes from the CMS and check if the hash the user sent us is valid. The problem here is that we need a list of hashes and the CMS needs to send them to our backend some way. Is there any other issue I'm missing? What about users trying all possible hashes?

Second scenario:

We receive the user's hash and send it back to the CMS. The CMS verifies that this hash really exists and tells us whether we can serve the content. Here, the problem is that extra requests have to be made (performance?).

Third scenario – which I think should fit in our case:

The user sends us their e-mail, ID and the hash the CMS generated for them. We share a secret key (the salt) with the CMS, and try to reconstruct the hash from e-mail and ID. If it matches, the user must've been authenticated in the CMS before, so we can serve the content.

The problem here is that we send the e-mail via URL. Now, the previous (insecure) implementation also did this, but I don't know how much of a privacy issue this is.

Bottom line: Is there anything I've missed in the above examples? Would the last scenario fit our case, or is there another easy method to authenticate a user when you don't have access to private data on your side of the scheme?

Answer 1

This proposed design does not take replay attacks into consideration. In the first scenario the "hash" is now the password, and therefore this hash (and the information used to create this hash), must be protected in the database and during transmission.

What you are trying to do is not new or unique. When you build something from scratch there are problems with design, implementation and compatibility with other systems. To avoid all of these pitfalls you should implement an RFC'ed standard such as 3-legged oauth: