3 ms·

> When good behavior is not forthcoming The only bad behaviour, not that I'd choose that terminology, I'm aware of was password reuse. What was bad on their si

> When good behavior is not forthcoming The only bad behaviour, not that I'd choose that terminology, I'm aware of was password reuse. What was bad on their side?

toomuchtodo 3y ago
https://developer.okta.com/blog/2018/06/11/how-to-prevent-your-users-from-using-breached-passwords https://developer.okta.com/blog/2018/06/11/how-to-prevent-yo... ("How to Prevent Your Users from Using Breached Passwords") | https://github.com/OktaSecurityLabs/passprotect-js https://github.com/OktaSecurityLabs/passprotect-js is an example. Good behavior: > The new NIST recommendations mean that every time a user gives you a password, it’s your responsibility as a developer to check their password against a list of breached passwords and prevent the user from using a previously breached password. SP 800-63 specifically: https://pages.nist.gov/800-63-3/ https://pages.nist.gov/800-63-3/ | https://pages.nist.gov/800-63-4/ https://pages.nist.gov/800-63-4/
- dpkonofa 3y ago
  This assumes the breached password occurrence was known in advance and, from what I have read so far about this, was not the case with the 23andMe accounts.
  - toomuchtodo 3y ago
    I will eat crow if it comes to light that this was entirely unavoidable on 23andme's part.
    - dpkonofa 3y ago
      You won’t have to. They could have forced MFA and been done with it. That doesn’t make it their fault that they didn’t. It just means they could have done better and assumed that at least some users (read: most) are ignorant about best practices with sensitive data. It’s not something they would be legally culpable for, though.
- robertlagrant 3y ago
  I agree that is a good idea, but that doesn't lay the blame of this so fully at their users' feet. This won't always catch password reuse attacks (now called "credential stuffing", I think), and is only a partial mitigation.

> When good behavior is not forthcoming The only bad behaviour, not that I'd choose that terminology, I'm aware of was password reuse. What was bad on their side?

toomuchtodo 3y ago

https://developer.okta.com/blog/2018/06/11/how-to-prevent-your-users-from-using-breached-passwords https://developer.okta.com/blog/2018/06/11/how-to-prevent-yo... ("How to Prevent Your Users from Using Breached Passwords") | https://github.com/OktaSecurityLabs/passprotect-js https://github.com/OktaSecurityLabs/passprotect-js is an example. Good behavior: > The new NIST recommendations mean that every time a user gives you a password, it’s your responsibility as a developer to check their password against a list of breached passwords and prevent the user from using a previously breached password. SP 800-63 specifically: https://pages.nist.gov/800-63-3/ https://pages.nist.gov/800-63-3/ | https://pages.nist.gov/800-63-4/ https://pages.nist.gov/800-63-4/

dpkonofa 3y ago
This assumes the breached password occurrence was known in advance and, from what I have read so far about this, was not the case with the 23andMe accounts.
- toomuchtodo 3y ago
  I will eat crow if it comes to light that this was entirely unavoidable on 23andme's part.
  - dpkonofa 3y ago
    You won’t have to. They could have forced MFA and been done with it. That doesn’t make it their fault that they didn’t. It just means they could have done better and assumed that at least some users (read: most) are ignorant about best practices with sensitive data. It’s not something they would be legally culpable for, though.
robertlagrant 3y ago
I agree that is a good idea, but that doesn't lay the blame of this so fully at their users' feet. This won't always catch password reuse attacks (now called "credential stuffing", I think), and is only a partial mitigation.