Single point of failure when using signed IDs about rails-authentication-from-scratch HOT 5 OPEN

@ayushn21 thank you for taking the time to post this since I think it's valuable information. Since the API mentions that using a singed_id is "... particularly useful for things like password reset or email verification", I'm not too concerned. If the secret_key_base becomes compromised I'd imagine that the application would be vulnerable to multiple attacks.

However, I do think it's worth keeping this issue open to raise awareness and keep the conversation going. Thanks again!

from rails-authentication-from-scratch.

I appreciate you taking the time to highlight this though. I'm learning a lot!

from rails-authentication-from-scratch.

Also worth mentioning is that the same flaw exists if the session_token and remember_token are stored in plain text in the database. Again I'm assuming that an attacker has access to the database and secret_key_base. If somehow they do, then they can forge sessions and impersonate any user.

If those tokens are also stored with has_secure_password then the above loophole is closed as they won't have the plain text tokens they need to put into their forged cookie.

from rails-authentication-from-scratch.

particularly useful for things like password reset or email verification", I'm not too concerned

Yeah absolutely. In 99.9%, or even 99.99% of cases I'm sure it'd be totally fine!

If the secret_key_base becomes compromised I'd imagine that the application would be vulnerable to multiple attacks.

For sure. The app would be at serious risk if the key base was compromised. My aim with this issue was to suggest a method to minimise the exposure until a new key base can be deployed. Again making some serious assumptions about the attacker having access to sensitive information so this is all pretty low-risk "worst case scenario" stuff so just worth a chat about I reckon :)

from rails-authentication-from-scratch.

Happy to help! :)

from rails-authentication-from-scratch.