161–170 of 447 posts
I hate MFA. I get the "need", but it's a) generally shittily implemented, and c) frequently manipulated/enforced not for the right reasons (notably to force you to surrender your phone number)
I actually kind of like TOTP, since I can choose the implementation I want to use, and make backups, and so on. I loathe having to use any kind of bespoke MFA app, and I just resent the use of SMS for MFA.
NIST best practice recommendations state: * Require more than 8 characters * Don't require special characters * Don't force the user to reset their password * Do check for compromised passwords * Require MFA * ... All very sensible. https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
> * Require MFA Using some kind of OTP authenticator app or device and __NOT__ SMS!
Every service of course has the option to print backup keys. Maintaining those (in secure offsite location) over years takes some effort.
In another blog post, linked from this one, Bruce says that the XKCD scheme of stringing together a series of words is no longer safe: > Modern password crackers combine different words from their dictionaries. This is why the oft-cited XKCD scheme for generating passwords — string together individual words like “correcthorsebatterystaple” — is no longer good advice. The password crackers are on to this trick. Is tha…
For example using a 6 word pass phrase from the above 10000 word list would on average require 5e23 attempts to correctly guess it. For credential stuffing this is absolutely impractical. For cracking a leaked password hash we can figure out how secure it is.
We assume that the service properly salts the passwords, so a rainbow table can't be used. If salted bcrypt hashes are used, a benchmarked 4-gpu rig did ~160 hashes/s, so even assuming a nation-state with 1E9 times as much computing power, we get 1.6e11 hashes/s, so this gives us on average 3.1e12 seconds to crack, which is about 100,000 years. Which means that no-one (pre-quantum) can crack that password.
NIST best practice recommendations state: * Require more than 8 characters * Don't require special characters * Don't force the user to reset their password * Do check for compromised passwords * Require MFA * ... All very sensible. https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
Disclosure: I am the cofounder https://www.clerk.dev Here's the direct link to NIST 800-63B - it's really a fantastic document with sensible recommendations on every authentication method: https://pages.nist.gov/800-63-3/sp800-63b.html The tedious part of NIST's password requirements is "Do check for compromised passwords" HaveIBeenPwned exists, but most open source tools don't leverage it and this requirement goes o…
NIST best practice recommendations state: * Require more than 8 characters * Don't require special characters * Don't force the user to reset their password * Do check for compromised passwords * Require MFA * ... All very sensible. https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
I have multiple financial accounts that still insist on using public-knowledge security questions (which of course I've given fake answers saved in my password manager) instead of just letting me set up proper 2FA. It's infuriating.
The saddest thing is banks can't be too secure. If they were, then they would be too hard for normal people to use and they would get locked out of their funds.
Earlier quoted context omitted.
Wait, what? That never happened to me. How do you go and find out your password then? Trial and error?
They might just truncate the password during login as well. I was able to login to my online banking using only the first five digits of my password not more than 3 years ago.. They fixed it in the meantime but I'm still worried.
> I Hate Password Rules I hate passwords altogether. In this day and age, nearly all instances of password usage can be replaced by public key cryptography for a vastly improved user experience. And, of course, for a net gain in security.
I’d really love the W3C to come out with some elements that provide: 1) Communication of complexity requirements 2) Explicit password manager fill targets 3) An endpoint for a password manager to rotate passwords automatically. (and the validity period) All of these would be backwards compatible with grandmas that write passwords on post-its and mouldering IT policies that snub NIST recommendations. Sure, webauthn is…
With that and a well-known endpoint for changing passwords (not quite the same thing as what you’re describing; https://w3c.github.io/webappsec-change-password-url/) we are moving in that direction.