4 ms·

The service would likely accept a hash, not the raw password. If it's rate limited more aggressively than the normal login endpoint, I don't see how it could b

The service would likely accept a hash, not the raw password. If it's rate limited more aggressively than the normal login endpoint, I don't see how it could be any more dangerous. Anyone on the internet can already query any site with a guess for your username/password - if they're right, the request will succeed. How is that different?

scottlamb 8y ago
They can't check a supplied hashed password against their hashed password database unless they're using the same algorithm and (random) salt.
Kalium 8y ago
> The service would likely accept a hash, not the raw password. Either everyone would use the same unsalted hashes (bad practice) or everyone would use the same salts (bad practice). In either case, this requires widespread use known bad practices. If you're not familiar, these are considered bad practices because they allow for the construction of rainbow tables - https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table These are bad because they allow hashes to be reversed. > If it's rate limited more aggressively than the normal login endpoint, I don't see how it could be any more dangerous. Given a little bit of time, rate limiting isn't actually that big of an obstacle. Especially if you don't need to compromise a given account and can use a botnet to trawl for accounts in general. > Anyone on the internet can already query any site with a guess for your username/password - if they're right, the request will succeed. How is that different? This imagines a central service querying N others with credentials to see if each service knows them. Imagine compromising one service. Then people are sending you usernames and passwords for hundreds of other services. You won't need to query any other service, the credentials will come to you and the user will have no indication!

scottlamb 8y ago

They can't check a supplied hashed password against their hashed password database unless they're using the same algorithm and (random) salt.

Kalium 8y ago

> The service would likely accept a hash, not the raw password. Either everyone would use the same unsalted hashes (bad practice) or everyone would use the same salts (bad practice). In either case, this requires widespread use known bad practices. If you're not familiar, these are considered bad practices because they allow for the construction of rainbow tables - https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table These are bad because they allow hashes to be reversed. > If it's rate limited more aggressively than the normal login endpoint, I don't see how it could be any more dangerous. Given a little bit of time, rate limiting isn't actually that big of an obstacle. Especially if you don't need to compromise a given account and can use a botnet to trawl for accounts in general. > Anyone on the internet can already query any site with a guess for your username/password - if they're right, the request will succeed. How is that different? This imagines a central service querying N others with credentials to see if each service knows them. Imagine compromising one service. Then people are sending you usernames and passwords for hundreds of other services. You won't need to query any other service, the credentials will come to you and the user will have no indication!