3 ms·

If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. If someone else is, you migh

If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. If someone else is, you might as well use OAuth, and allow a choice of provider, but the integration effort is non-trivial (but far less than protecting your site against those looking to breach your hoard of stored treasure, other people’s passwords). The other alternative is to support TOTP and let people use whatever authenticator they want.

kcartlidge 2y ago
> If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. Without specifically commenting on the relative merits of all the auth options being mentioned in the thread, I do feel it worth pointing out that "if you accept id+password" you definitely should not be storing them. And neither should someone else on your behalf. Using one-way cryptographic hashes of passwords is well documented and nobody should have the "hoard of stored treasure, other people’s passwords" even with id+password as the auth mechanism.
- PeterWhittaker 2y ago
  Also well documented are attacks against stores of hashed passwords, esp. pre-built dictionary attacks. There are more ways to do that wrong than right. Of course, that is irrelevant to my point: even if you do store them all properly, you are still going to get attacked. Don’t give people such terrible advice unless you also tell them how to protect themselves.
  - kcartlidge 2y ago
    The phrase 'terrible advice' is unwarranted when it comes to a simple comment saying to use one-way cryptographic hashes rather than storing passwords. I offered a technically correct warning for a single case, and also specifically said I wasn't commenting on whether that auth method should be used or not. I'm not required to offer a security tutorial, but yes it's true that storing anything, even hashes, is a security risk. So if it helps any other readers they can somewhat mitigate dictionary attacks by using salts and possibly peppers.
deleted 2y ago
[deleted]

kcartlidge 2y ago

> If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. Without specifically commenting on the relative merits of all the auth options being mentioned in the thread, I do feel it worth pointing out that "if you accept id+password" you definitely should not be storing them. And neither should someone else on your behalf. Using one-way cryptographic hashes of passwords is well documented and nobody should have the "hoard of stored treasure, other people’s passwords" even with id+password as the auth mechanism.

PeterWhittaker 2y ago
Also well documented are attacks against stores of hashed passwords, esp. pre-built dictionary attacks. There are more ways to do that wrong than right. Of course, that is irrelevant to my point: even if you do store them all properly, you are still going to get attacked. Don’t give people such terrible advice unless you also tell them how to protect themselves.
- kcartlidge 2y ago
  The phrase 'terrible advice' is unwarranted when it comes to a simple comment saying to use one-way cryptographic hashes rather than storing passwords. I offered a technically correct warning for a single case, and also specifically said I wasn't commenting on whether that auth method should be used or not. I'm not required to offer a security tutorial, but yes it's true that storing anything, even hashes, is a security risk. So if it helps any other readers they can somewhat mitigate dictionary attacks by using salts and possibly peppers.

deleted 2y ago

[deleted]