4 ms·
One bit of awfulness the article missed: Rather than scanning for the username and then checking whether the password is correct, it scans for a match on both u
by Sniffnoy 6y ago
One bit of awfulness the article missed: Rather than scanning for the username and then checking whether the password is correct, it scans for a match on both username and password. So if you have the right username but the wrong password, it still has to check every single username to conclude this; it won't stop when it gets to the username you entered.
I mean, not that it should be scanning through a list to find the right username, but still...
(And yeah, I suppose that would allow for some sort of username enumeration via a timing attack, but somehow I don't think that's the reason they didn't do that here...)
- champtar 6y agoYou assume that username are unique in this DB, maybe they support multiple password :)
- onemiketwelve 6y agoWhat a neat feature ;)
- Viliam1234 6y agoIf you forget a new password, you can create a new one, and then if you remember the old password later, you can use both. Is this so different in principle from supporting multiple methods of authentication? :D
- CodesInChaos 6y agoI don't think it matters. With an index on username you don't need to scan. Without an index (like in the example), you have to scan on average half the table for existing names and the full table for missing ones. Adding a check for the password won't affect performance in a way that matters. The main reason why you can't do this in a correctly written application is that it's incompatible with salted hashes, since you need to get the salt from the database to verify the hash. (You should calculate the hash in the app server, since it's expensive and scaling app servers is usually easier and cheaper than scaling db servers)