4 ms·

It's sounding like it's too difficult to keep up with password security to try to do it all yourself. You'd be better outsourcing it such as with OAuth if you c

It's sounding like it's too difficult to keep up with password security to try to do it all yourself. You'd be better outsourcing it such as with OAuth if you can.

chinathrow 11y ago
Do you mean outsurcing the to OAuth regarding the various implementations or outsourcing to an OAuth provider?
continuational 11y ago
While it certainly would be nice to outsource this problem, ph.hash("s3kr3tp4ssw0rd") ph.verify(hash, "s3kr3tp4ssw0rd") Is pretty damn easy.
- ajross 11y ago
  You're missing the point (which is hilarious, because the very first sentence of the linked article spells it out explicitly). The APIs for password hashing are simple, and always have been (c.f. man 3 crypt). It's the problem area that is complicated and rapidly changing. And use of APIs and mechanisms that just a few years back were Best Practices is now discouraged. That's not something that can be treated by a cute Python API.
  - creshal 11y ago
    The best practice a few years ago was "use the best PBKDF available", which hasn't changed – just what algorithm to use. This isn't different from any other part of crypto – we have a constant algorithm churn as we identify and replace problematic algorithms. And OAuth is no exception: If you implemented OAuth five years ago, it was OAuth1, which was obsolete and ripe for replacement… four years ago.
    - ajross 11y ago
      Uh... the specific advice I was replying to was precisely to use a specific python wrapper around Argon2, which is certainly not isomorphic to the "best PBKDF available" (even if it might be right now). And the OAuth point is misdirected: we're talking about hash choices here, which OAuth is not. An OAuth1 client, while perhaps obsolete for other reasons, would certainly be protected against the need for a change in password hash, because all that stuff happens upstream and it never sees the password. That is by design, therefore remote authentication against highly-trusted password verifiers[1] is a good idea, which is what the great-grantparent post was saying. [1] Which, sure, has its own list of worries unrelated to hash behavior.
      - creshal 11y ago
        So what is your point then? No matter what you do – whether you verify password yourself or externally – the state of the art constantly changes and you have to update your code either way. There's no escape from that. The reasons change, but not the code churn.
        ajross 11y ago
        Uh... no. That's exactly wrong. If bcrypt or whatever gets broken tomorrow, and my OAuth provider needs to reset all the passwords in the database (Linode literally did this last week, though not because of a hash change, it's a common kind of thing), I don't need to change a line of code. Ergo, if you're worried about changes to password hash vogues, OAuth is a good idea. Thus the point way upthread, which both you and the other poster seem to have missed.
        creshal 11y ago
        Because it's a nonsensical point. You trade one very simple thing to worry about – password hashing algorithms, for which you can count all variations in the past ten years on one hand – with a massively complex system like OAuth (1.0? 1.0a? 2.0?), which in turn relies on TLS for transport security, for which best practices change every two or three months. If bcrypt gets broken tomorrow, your passwords are safe until you have a data breach. If OAuth gets broken tomorrow, you're immediately at risk.
- seanwilson 11y ago
  What about the code for taking initial passwords, changing passwords, password recovery, securing login forms, storing passwords, transitioning to new hashes methods and even 2-factor authentication? OAuth providers would do all this for you in an undoubtable more secure way than most people would have time for.
- deleted 11y ago
  [deleted]
tptacek 11y ago
Implementing OAuth to avoid picking a password hash is a crazy security tradeoff. This is the kind of thing that made me feel like the Password Hashing Contest might be a net negative for systems security. In reality, despite what this blog post says, you could select the worst of the password hashes --- PBKDF2 --- in relatively weak parameters, and still be fine. If you give nerds 3-4 things that do the same thing, we will find 10^(3-4) different ways to have arguments about them.
fryguy 11y ago
Unfortunately, the user experience with the nascar buttons is pretty awful.

It's sounding like it's too difficult to keep up with password security to try to do it all yourself. You'd be better outsourcing it such as with OAuth if you can.

chinathrow 11y ago

Do you mean outsurcing the to OAuth regarding the various implementations or outsourcing to an OAuth provider?

continuational 11y ago

While it certainly would be nice to outsource this problem, ph.hash("s3kr3tp4ssw0rd") ph.verify(hash, "s3kr3tp4ssw0rd") Is pretty damn easy.

ajross 11y ago
You're missing the point (which is hilarious, because the very first sentence of the linked article spells it out explicitly). The APIs for password hashing are simple, and always have been (c.f. man 3 crypt). It's the problem area that is complicated and rapidly changing. And use of APIs and mechanisms that just a few years back were Best Practices is now discouraged. That's not something that can be treated by a cute Python API.
- creshal 11y ago
  The best practice a few years ago was "use the best PBKDF available", which hasn't changed – just what algorithm to use. This isn't different from any other part of crypto – we have a constant algorithm churn as we identify and replace problematic algorithms. And OAuth is no exception: If you implemented OAuth five years ago, it was OAuth1, which was obsolete and ripe for replacement… four years ago.
  - ajross 11y ago
    Uh... the specific advice I was replying to was precisely to use a specific python wrapper around Argon2, which is certainly not isomorphic to the "best PBKDF available" (even if it might be right now). And the OAuth point is misdirected: we're talking about hash choices here, which OAuth is not. An OAuth1 client, while perhaps obsolete for other reasons, would certainly be protected against the need for a change in password hash, because all that stuff happens upstream and it never sees the password. That is by design, therefore remote authentication against highly-trusted password verifiers[1] is a good idea, which is what the great-grantparent post was saying. [1] Which, sure, has its own list of worries unrelated to hash behavior.
    - creshal 11y ago
      So what is your point then? No matter what you do – whether you verify password yourself or externally – the state of the art constantly changes and you have to update your code either way. There's no escape from that. The reasons change, but not the code churn.
      - ajross 11y ago
        Uh... no. That's exactly wrong. If bcrypt or whatever gets broken tomorrow, and my OAuth provider needs to reset all the passwords in the database (Linode literally did this last week, though not because of a hash change, it's a common kind of thing), I don't need to change a line of code. Ergo, if you're worried about changes to password hash vogues, OAuth is a good idea. Thus the point way upthread, which both you and the other poster seem to have missed.
        creshal 11y ago
        Because it's a nonsensical point. You trade one very simple thing to worry about – password hashing algorithms, for which you can count all variations in the past ten years on one hand – with a massively complex system like OAuth (1.0? 1.0a? 2.0?), which in turn relies on TLS for transport security, for which best practices change every two or three months. If bcrypt gets broken tomorrow, your passwords are safe until you have a data breach. If OAuth gets broken tomorrow, you're immediately at risk.
seanwilson 11y ago
What about the code for taking initial passwords, changing passwords, password recovery, securing login forms, storing passwords, transitioning to new hashes methods and even 2-factor authentication? OAuth providers would do all this for you in an undoubtable more secure way than most people would have time for.
deleted 11y ago
[deleted]

tptacek 11y ago

Implementing OAuth to avoid picking a password hash is a crazy security tradeoff. This is the kind of thing that made me feel like the Password Hashing Contest might be a net negative for systems security. In reality, despite what this blog post says, you could select the worst of the password hashes --- PBKDF2 --- in relatively weak parameters, and still be fine. If you give nerds 3-4 things that do the same thing, we will find 10^(3-4) different ways to have arguments about them.

fryguy 11y ago

Unfortunately, the user experience with the nascar buttons is pretty awful.