So we all know that it’s important for an authentication system not to reveal whether a user account exists or not and instead just provide a general message such as, “The account has been created in case you have provided a valid email address”, etc.
However, I find this pretty useless as it is extremely easy to determine whether such an account exists or not if the developer hasn’t taken a timing attack into consideration.
The time difference between the application checking for a user, then posting the general message, versus the application actually creating an account and sending out an email (if this is not postponed), can be quite high.
So for simply checking an account the average time might be 0.015s whereas a real signup might take 0.200s.
I have tested several signup processes and found that the timing difference is pretty high and very easy to detect. While isn’t relevant to a bruteforce attack, as you can block this, it’s relevant in relation to revealing the information, that the account actually exists.
What measurements have you implemented against this, if any?
EDIT: For those who don’t think this is important, please refer to: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-responses and also https://cwe.mitre.org/data/definitions/204.html
“The account has been created in case you have provided a valid email address”
Can you please provide an example site that actually does this?
Not on top of my head, but it’s the right thing to do. See https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
Not sure where a timing attack is actually useful in this case. Most systems will tell you on the account creation screen if the username or email address is already in use.
A timing attack is not useful if the account creation reveals that be default, then the implementation is already flawed. This has been on the OWASP list for a long time.
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
That’s solved by a message queue. I made one for my CMS, that works both for registration and forms on pages. Everything is seemingly immediate, and the queue is polled every minute.
Normally you limit the amount actions an IP can do.
After that, just sleep randomly up to a second and will throw off allot timing attacks, if your that worried.
But even banks don’t do this…