That is going to be insanely annoying.
Could you explain? Unless you're using a really weak password or reusing passwords, how would it affect you?
Passwords already suck. Please don't make them suck even more.
121–129 of 129 posts
That is going to be insanely annoying.
Could you explain? Unless you're using a really weak password or reusing passwords, how would it affect you?
Passwords already suck. Please don't make them suck even more.
Please don't use passwords at all. They are wrong for so many reasons. Use emailed sign-in links.
Which, in general rely on your users email password .. which may not be as secure as their bank password, because "email doesn't handle money". So, to access your bank now crackers just need to get in to your email (which may be true anyway, of course 2FA helps in both cases).
The benefits of sign-in links are: a) you don't have to remember gazilion of passwords b) you don't have to use password managers c) you can setup a really strong passphrase for your email and actually remember it because it's the only one you have to. And of course set up strong MFA or whatever d) you don't have to setup MFAs on services and giving them more personal info(phone number) than they really need e) for me as a developer it's also easier to implement actually
Earlier quoted context omitted.
Why is it inefficient? Is the HIBP API too slow? How slow is too slow? My principle is that you should not let people sign up with breached passwords at all - don't make judgment calls about which breaches matter, and whether you think it's the same user or not, or the password is strong enough or not. Just ban the passwords. (Remember that no actual data breach contains 20 trillion passwords.)
I'm actually withdrawing my argument, as I mentioned in the sibling comment to this one. The HIBP API does introduce a lot of latency, but you can do this checking with Troy Hunt's entire password database locally. He provides it for free.
The world has decided that making me go through a Google CAPTCHA when registering a new account - a process that takes me several seconds of active mental effort - is fine. If the check takes even 1 second of server time, is that noticeable?
Earlier quoted context omitted.
Bloom filters! B-trees! There are MUCH smarter ways to implement this than grepping a list line by line. I mean seriously who the hell would do that... If your bio isn't complete BS then surely you understand that proposed implementation is BS.
To clarify the context I was talking about, I mean online checking of a hashed user password against Troy Hunt's HIBP database of hashed passwords. The original context of this discussion was an API, not a local copy of the database. That being said I'm actually going to concede this argument, because on further investigation Troy Hunt provides the entire copy of his database freely for local lookups. Once you hash t…
And I thought we were getting away from arcane rules for passwords. Now you have to avoid every compromised password from any unrelated account? I may use random passwords, but I don't expect the typical consumer to do the same. Sometimes I simply don't care about security for a one off account on a free service where I'll happily use the simplest permutation of "password" for the password.
Most people don't know how to make a good password. So don't let them make a bad password, and make that easy by providing a button that generates good ones. "It has to be new" is about as elegant as you can get for password rules. You can use any secure method you want. Whatever characters you want, just don't do it wrong. If you want it to be easier, press the button. Even with a one-off account, a complex password…
I say better for the service theoritically because I probably won't sign up (less of an issue since I moved to LastPass, but still annoying because so many sites don't work with autofill.)
Earlier quoted context omitted.
Most people don't know how to make a good password. So don't let them make a bad password, and make that easy by providing a button that generates good ones. "It has to be new" is about as elegant as you can get for password rules. You can use any secure method you want. Whatever characters you want, just don't do it wrong. If you want it to be easier, press the button. Even with a one-off account, a complex password…
Better for the service, theoritically, but not better for me. I say better for the service theoritically because I probably won't sign up (less of an issue since I moved to LastPass, but still annoying because so many sites don't work with autofill.)
Earlier quoted context omitted.
Better for the service, theoritically, but not better for me. I say better for the service theoritically because I probably won't sign up (less of an issue since I moved to LastPass, but still annoying because so many sites don't work with autofill.)
(FYI lastpass is a bit of a shitshow, I'd recommend using a different service)
Earlier quoted context omitted.
There’s something that I don’t really understand regarding password managers which maybe you could explain. How is using a password manager to manage multiple passwords more secure than using a single password everywhere? In the case of a password manager, if your computer is breached, then all passwords are breached. If your passwords are hosted encrypted on a website, then if that website is breached, the master pa…
If your computer is "breached" then it doesn't matter where your passwords come from. They could just run a keylogger and get them that way. It really depends on your threat model. No system is perfect and we're mostly balancing security and convenience most of the time. The same password everywhere is super convenient, but only one site needs to fail and it's all over. A cloud password manager with unique passwords…
Earlier quoted context omitted.
(FYI lastpass is a bit of a shitshow, I'd recommend using a different service)
Can you expand on it, and which choices are better?
Personally I use 1password, but there are loads of other ones that don't have a list of security breaches on their wikipedia page.