5 ms·

Reminds me of (clever?) demo site that disallowed passwords for users if they were valid logins to other common services. That is, it would present an error on

by ghayes 8y ago

Reminds me of (clever?) demo site that disallowed passwords for users if they were valid logins to other common services. That is, it would present an error on registration "Please do not use your LinkedIn password."

Kalium 8y ago
The implications of how they would need to implement that are a little scary.
- ahakki 8y ago
  I bet the message got the point across.
  - infogulch 8y ago
    Yeah but I bet the implementation brushes up against things that have been used to come to a conviction under CFAA. I'm no lawyer but it seems like a big liability to me.
    - Kalium 8y ago
      Yeah. When setting a password on a service, most people are not knowingly authorizing that service to use their credentials to try to log in to other services...
- Spivak 8y ago
  It would actually be pretty cool if this was actually a service offered by those major services. Obviously very rate limited. Say example.com/.well-known/password-check You provide a username or email and a password and if you get it right it will let you know and lock their account and require a reset when they log on next. The someone like haveibeenpwned can run a meta service to check every service that registers with them. I haven't thought through the security implications of this but it seems pretty mild on the surface. I mean there's denial of service potential but only when their password has been compromised so... good?
  - infogulch 8y ago
    Could that not be used to reveal the password? Sure it won't work on this site anymore, but now the random attacker has a username:password combo. Also, doesn't that just hand over the user's password to the site hosting major.service//password-check? Maybe the user is security conscious already, now their strong password is sitting in plaintext on major.service's misconfigured logs. This just doesn't seem like a good idea to me. Edit: Or a hacker gets into linkedin, now he's literally being fed the actual username/password combinations of every single person that signs up to any website anywhere. This just gets worse the more I think about it.
    - maddyboo 8y ago
      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!
Buge 8y ago
Evilpass https://news.ycombinator.com/item?id=13674890 https://news.ycombinator.com/item?id=13674890

by ghayes 8y ago

Kalium 8y ago

The implications of how they would need to implement that are a little scary.

ahakki 8y ago
I bet the message got the point across.
- infogulch 8y ago
  Yeah but I bet the implementation brushes up against things that have been used to come to a conviction under CFAA. I'm no lawyer but it seems like a big liability to me.
  - Kalium 8y ago
    Yeah. When setting a password on a service, most people are not knowingly authorizing that service to use their credentials to try to log in to other services...
Spivak 8y ago
It would actually be pretty cool if this was actually a service offered by those major services. Obviously very rate limited. Say example.com/.well-known/password-check You provide a username or email and a password and if you get it right it will let you know and lock their account and require a reset when they log on next. The someone like haveibeenpwned can run a meta service to check every service that registers with them. I haven't thought through the security implications of this but it seems pretty mild on the surface. I mean there's denial of service potential but only when their password has been compromised so... good?
- infogulch 8y ago
  Could that not be used to reveal the password? Sure it won't work on this site anymore, but now the random attacker has a username:password combo. Also, doesn't that just hand over the user's password to the site hosting major.service//password-check? Maybe the user is security conscious already, now their strong password is sitting in plaintext on major.service's misconfigured logs. This just doesn't seem like a good idea to me. Edit: Or a hacker gets into linkedin, now he's literally being fed the actual username/password combinations of every single person that signs up to any website anywhere. This just gets worse the more I think about it.
  - maddyboo 8y ago
    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!

Buge 8y ago

Evilpass https://news.ycombinator.com/item?id=13674890 https://news.ycombinator.com/item?id=13674890