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?
Prevent users registering with passwords from data breaches
111–120 of 129 posts
Re: Prevent users registering with passwords from data breaches
#112Earlier quoted context omitted.
What do you mean by "which dimension"? Login attempts per second. How you do it? Depends, but basic answer is captcha. How do you make sure normal user are not affected? You monitor the login attempts and use the metadata, like ip address of last successful login and valid/expired cookies, to assign the "level of trust" on that particular attempt. The lower the "level of trust" the longer it should take. If you have…
You're starting to build a hand-wavy levitation machine though ("monitoring metadata", "level of trust"), and confirming that it's not so trivial, which is the assertion that started this thread. And captcha only makes brute-force somewhat more expensive. You likely have to use a 3rd party captcha service (like Recaptcha) which incurs network volume amplification since you need a req/res to Google just to render GET…
I didn't change my argument. "Just bruteforce the login page" is not a go-to method of the competent attacker. Why? Because it's trivial to stop it.
You want simple concrete example of how to stop all that "unlimited amount of ip addresses with captcha solver service" stuff? No more than 20 attempts per day with ip different from the ip of the last successful login. Here it is, you just solved the "bruteforce problem". That's all you have to do. Other things are just quality of life improvements.
Re: Prevent users registering with passwords from data breaches
#113This is over the top. Even enforcing password complexity is over-rated. For online attacks, an attacker can't even try the top 1000 passwords on for an account in any major website in reasonable time without triggering the alarm, as they all(?) have rate limiting (usually in the form of account lockdown after single-digit failed attempts). For offline attacks, there first needs to be a breach. While they undoubtedly…
Making credential stuffing harder is the main reason to do this. Credential stuffing works because users reuse credentials across sites. If someone attempts to use a password from the HIBP database, the two most likely cases are that it's extremely common or the same person is reusing it. Extremely common passwords are bad for all sorts of reasons and the same person reusing a breached password makes the account vulnerable to credential stuffing.
Re: Prevent users registering with passwords from data breaches
#114Earlier quoted context omitted.
> Aside, how do you implement account-locking without making it trivial for users to DoS each other that way? By adding an (increasing) time delay after each failed attempt. However many sites, banking in particular, just lock your account and you have to call them on the phone to reopen it. Totally open for massive DoS but the world still stands.
Well, that introduces trivial DoS, so it doesn't satisfy my question. Notice that banking websites can get away with it, yet surely you weren't only talking about banking when you said "online attacks".
Sorry, I tried to say 2 things:
1. Your simple solution: add a 5 second delay after each failed attempt per username OR ip address.
2. It seems that sites that do account lock-outs don't suffer from DOS attacks, for some reason.
Re: Prevent users registering with passwords from data breaches
#115Earlier quoted context omitted.
If that happens commonly, the original password with a 1 appended will probably eventually appear in a future HIBP database. In fact, the user could continue adding 1s until they either give up and try something different, or until it becomes uncommon enough.
Here's an example of that user experience: User: Set my password to 'monkey' Website: Sorry that's a common password User: OK, set my password to 'monkey1' Website: Sorry that's a common password User: What?! OK, set my password to 'monkey123' Website: Sorry that's a common password User: Grr! Set my password to 'monkey123fuckyou!!' Website: Sorry that's a common password User: Screw this, I'll just sign up to your c…
That doesn’t seem too far off from what I would expect, if your site actually cares about the data your users store there.
I wouldn’t recommend it, but you could try a slightly scarier explanation. (“Sorry, hackers have cracked this password on other sites. If you use this password elsewhere, you should consider immediately changing it.”)
Re: Prevent users registering with passwords from data breaches
#116All of those rely on Troy Hunt's API. Which may be fine for some people, yet others may uncomfortable introducing an external dependency. I generally recommend avoiding external API dependencies if you can. Here's a python implementation using bloom filters which avoids storing the whole list (need to store ~1 gig), yet still gives you very good accuracy: https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2..…
There’s no reason you can’t do both... simply build your internal code to check against multiple sources. You can asynchronously hit your bloom filter, HIBP, DeHashed, etc. and cut short whenever there is a hit.
In this way you get the best of all worlds; speed, highest degree of accuracy, and reduced dependency on a single external API.
Re: Prevent users registering with passwords from data breaches
#117Earlier quoted context omitted.
Well there is one important factor about these 20 trillion passwords: are they associated with real user accounts? If not then it really doesn't matter that they got published. They're useless to hackers without knowing what email to type in. The attack model is that the attacker actually has to log into a website and you don't get 20 trillion attempts.
Never underestimate the ingenuity of the user. They might search for a list of good passwords, find it, and pick one. > The attack model is that the attacker actually has to log into a website Not to find the password. If it was then nobody would get upset about plaintext password storage.
Well if we're talking about the possibility of an offline attack against a password database that's a bit different. The standards for a good password are higher for that attack.
But anyway if you pick a password from a list of 20 trillion where the offline attacker knows the list, it doesn't actually help them much because a single selection from 20 trillion options has 44 bits of entropy.
Passwords that users choose typically have less entropy than that afaik
Re: Prevent users registering with passwords from data breaches
#118It might be frustrating for users to have their typed password rejected without an explanation. Since there’s no authoritative list of compromised passwords they would have to take your word for it.
Wouldn’t a better solution be to increase password requirements until users are forces to generate one using a password manager? If you can memorize a password it’s probably not secure.
Re: Prevent users registering with passwords from data breaches
#119Earlier quoted context omitted.
Never underestimate the ingenuity of the user. They might search for a list of good passwords, find it, and pick one. > The attack model is that the attacker actually has to log into a website Not to find the password. If it was then nobody would get upset about plaintext password storage.
Well if we're talking about the possibility of an offline attack against a password database that's a bit different. The standards for a good password are higher for that attack. But anyway if you pick a password from a list of 20 trillion where the offline attacker knows the list, it doesn't actually help them much because a single selection from 20 trillion options has 44 bits of entropy. Passwords that users choos…
Most passwords are worse, yeah, but 44 bits isn't great. With a fast hash that's less than a GPU-week. It's basically enough if you use bcrypt, but even then it's not protected from an attacker with a lot of money to throw at it. (8 GPUs per server, 10 servers per rack, 50 racks, suddenly you're hashing work-factor-10 bcrypt passwords at about 2 million per second and average cracking time is 50 days.)
Re: Prevent users registering with passwords from data breaches
#120I need password fields to: 1)not silently fail when I try a 64 character (or 32 character) password 2)not fail and say my password is "too short" when it is 32 characters and you have an unrevealed maximum password length of fewer characters than that. 3)just all-around quit failing when my password is totally fine, it's a quasi-random string of letters, numbers, and symbols and I'll never type it... oh yeah 4)don't…
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…
I've probably made accounts with 100+ or so different websites or services. Eventually this turns into a game of statistics: https://haveibeenpwned.com/ lists no less than 6 mass breaches my account details have ended up in through no fault of my own, all of them including at least email addresses and password hashes (if not plaintext passwords)
(edit: Actually, I've recalled at least a 7th service that has been compromised that HIBP doesn't list)
That's either 6 times my bank account password gets leaked... or 0 times if I use unique passwords. I strongly suspect there are more breaches that HIBP simply isn't aware of with my information in them. Additionally, I need to rotate either 600 (!) or merely 6 different passwords to re-secure my accounts. So, obviously, unique passwords are a big win here.
> If your passwords are hosted encrypted on a website, then if that website is breached, the master password you send it will be visible to the attacker, and thus all passwords are breached.
I use an offline password manager specifically because of this reason. Still, needing to pwn any of 5 targets to get my bank account (me, my bank, my password service, my email provider, or my phone provider) isn't much worse than needing to pwn any of 4 targets (me, my bank, my email provider, or my phone provider), and both are much better than needing to pwn any of 100+ targets, some of which have terrible security and are probably already pwned without even knowing it.
So, options for unique passwords:
Memorize 100+ strong unique passwords: I "can't" do this.
Memorize 100+ weak unique passwords: Too weak to brute force attacks for my tastes.
Use a memorizable unique password generation scheme: Not unique enough for my tastes.
Memorize a few very strong unique passwords and use a password manager. This does have the weakness that capturing my master passwords via keylogger will get you all my accounts, instead of just all the important ones that I regularly use - but since "all the important ones that I regularly use" includes my email, that's just as good as pwning all of my accounts in my book.