4 ms·
That still goes back to user interface implementation. You can have a website that tells you "Bad password", and the user knows what it is. They fix it, on the
by kefka 12y ago
That still goes back to user interface implementation.
You can have a website that tells you "Bad password", and the user knows what it is. They fix it, on they go.
If there's a bad actor, it says "bad password". Same warning. Now, you slow down the response so that after 5-10 times, the website gets dog-slow. It's still useful if you're a legitimate user.
And if someone is script-attacking you, they're going to get an enumeration of your usernames by using a different script. Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways.
It's security through obscurity, and it's not that obscure. And it's bad UI.
- amckenna 12y agoIt's defense in depth. Why tell a probable attacker that they have the correct username if you can hide it from them. The less you give them the better. Most users will know if they got their username incorrect, it's right there in front of them on the screen. The slowed down responses (exponential back-off) is a the preferred method of rate limiting over account lockout. "Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways." Well if they can dump your DB it's game over for your whole app and possibly infrastructure anyways.