0

I had configured subdomains on a site to share forms authentication, however decisions were made to change one of websites over to a different domain. So now site A needs to send a user to the site B. Normally I would use something like Component Space to implement an SSO process for this, but this company doesn't already have access to any such library.

So my boss came up with a home rolled process. For this particular application, the risk is so low that we really just need to do "something" so we can say "we secured it". So I'm happy to do whatever makes him happy to just get the project moving. Though I can see us potentially having another project in the future where security may be a bigger concern and the thought of reusing this code would come up. So any notes about the security risks of this process are certainly appreciated in case I need to bring them up at a later point in time.

But really what I'm interested in at the moment is whether hashing is even providing a benefit in the following scenario:

Domain A is secured by a login. Domain B uses the following process to "authenticate" the user.

  1. Logged in user navigates to a page on domain A and it generates a token/guid to store in the database which is associated with that user's id.

  2. User is redirected to domain B with query parameters in the url which include the customer's id and a hash of the token from step 1).

  3. Domain B looks to the database to find the token that was saved in step 1) and hashes it, verifying the hash is the same as the one provided in the url query parameter.

Let's assume the token also expires after a period of time if not used.

While hashing sort of obfuscates the token, does it actually make it any more secure or would you say it would be no less secure to simply pass the token itself and just check that the token exists in the database?

Improve this question
5
  • Its def unique ... only thing to double check is that the token/guid is only generated AFTER the user logs in on domain A to prevent someone attempting to guess other tokens and hashing them externally. Another layer of security is you could add salt to the server side hashing on both domain A and domain B to make spoofing them even harder. Commented Sep 9, 2021 at 20:50
  • @CaffeineAddiction I would generate it at the time they are redirected to Site B, and I wouldn't use it if it's over 5 minutes (or some appropriately small amount of time) old. That's where the security comes from; but you didn't really address my question. I don't think hashing adds any value. You say add salt to make spoofing harder... but do you think someone is going to guess a guid that is only good for 5 minutes AND use it with the right customer id AND do it during the short window of time after that user happened to click the link? Continued... Commented Sep 9, 2021 at 21:08
  • I think if someone intercepted the link and used it right away then that's a threat... but at that point hashing won't stop them from using the link. So what's the purpose of hashing here? Commented Sep 9, 2021 at 21:12
  • Depending on how you generate the GUID, others from previous sessions could be gessable. Hashing (as long as its server side and not clientside) 100% adds security. Again, I would go one step further and have a shared secret on both servers used as salt in the hashing process. Commented Sep 9, 2021 at 23:03
  • UID could be an increasing integer ... im guessing its not, but in the event that it was as long as you hash it serverside with salt ... it wont matter. This is because instead of a UID of 1 you end up w/ a value of 8fa14cdd754f91cc6554c9e71929cce7 Commented Sep 9, 2021 at 23:06

1 Answer 1

Reset to default
1

No, hashing doesn't make this process more secure. There are two main benefits to hashing in a context like this one: one, to provide a placeholder for a large value, and two, to provide a value which cannot be inverted.

However, here, the credential you're sending is essentially a bearer token. It would be just as secure to send the original token, since both domains would query the same database and validate the credentials. Forging a different token wouldn't work, because it's in the database, and assuming it's a v4 (random) UUID generated by a CSPRNG, then it cannot be guessed.

There are a couple of contexts in which you might want to do something different. If the two domains don't share a database, you could issue some sort of signed token (using HMAC with a shared key or a digital signature) from one to the other, including the user ID and other information in the body of the token covered by the MAC or signature.

The other context in which this would be valuable is if you must send additional data (e.g., a session ID) from one domain to the other without using a shared data store. However, in such a case, the session ID is probably private and would also need to be encrypted, so you could only send data which is not private (e.g., a database ID) in plaintext with a MAC or signature.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.