Prevent users registering with passwords from data breaches • Hacker News Board

Re: Prevent users registering with passwords from data breaches

#101

Post by hombre_fatal » Sat, Jan 19, 2019, 1:51 PM UTC

air7 wrote: post #90

hombre_fatal wrote: post #79

Earlier quoted context omitted.

Our solution for a bitcoin casino was to generate passwords for users. But you can imagine how few sites can get away with such a thing. Our create-password input was a disabled textfield with a reroll button. Before that, attackers would just wait for new usernames to appear on the scoreboard/chat and check them against password dumps. The easy come, easy go nature of bitcoin made it particularly lucrative. Password…

> 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".

Re: Prevent users registering with passwords from data breaches

#102

Post by epriest » Sat, Jan 19, 2019, 1:57 PM UTC

air7 wrote: post #76

This 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…

> 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).

This is empirically a practical attack: attackers successfully executed a common password brute force attack against GitHub in late 2013 by using a botnet with 40,000 distinct remote addresses:

https://github.blog/2013-11-20-weak-passwords-brute-forced/

Re: Prevent users registering with passwords from data breaches

#103

Post by tialaramex » Sat, Jan 19, 2019, 2:03 PM UTC

throwawaymath wrote: post #8

bijection wrote: post #6

Earlier quoted context omitted.

Any known password is no longer a particularly strong one.

That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?

Yes, it's just safer. We do this _all the time_ in the Web PKI.

Remember the "Debian weak keys"? What's weak about those particular keys?

Nothing. Nothing whatsoever. Those keys aren't special in any way. Except, Debian shipped releases that always picked one of these key pairs. So anyone with a mind to can go find the list of private keys that corresponds to these particular public keys and thus we don't let you use those public keys any more.

(You can go try this if you don't believe me, submit a CSR to your preferred public CA asking for a certificate for one of the Debian Weak Keys, it will be rejected and there may or may not be an explanation attached saying your keys are crap and to get new ones)

Whole swathes of keys are blacklisted. ROCA is another example, somebody took one mathematical short-cut too many in their optimised design for RSA key generation, and so the resulting keys all have this very obvious structure that's exploitable (not easily, but enough that a sovereign entity could definitely break them). So we just blacklisted all those keys.

If you pick truly random keys you'll never notice this in a lifetime because of statistics, it's just some code on the issuer's systems that you never need to care about.

Re: Prevent users registering with passwords from data breaches

#104

Post by throwawaymath » Sat, Jan 19, 2019, 2:27 PM UTC

darkpuma wrote: post #70

throwawaymath wrote: post #22

Earlier quoted context omitted.

The harm is the principle of it. You should not design a system that greps through e.g. every single breach dump for arbitrary passwords every single time someone tries to sign up for your service. That's maddeningly inefficient.

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 the user password to match the database hashes you can introduce the optimizations you mentioned, and in any case it shouldn't introduce intolerable latency to do that lookup locally.

Re: Prevent users registering with passwords from data breaches

#105

Post by throwawaymath » Sat, Jan 19, 2019, 2:28 PM UTC

geofft wrote: post #26

throwawaymath wrote: post #22

Earlier quoted context omitted.

The harm is the principle of it. You should not design a system that greps through e.g. every single breach dump for arbitrary passwords every single time someone tries to sign up for your service. That's maddeningly inefficient.

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.

Re: Prevent users registering with passwords from data breaches

#106

Post by throwawaymath » Sat, Jan 19, 2019, 2:32 PM UTC

Buttons840 wrote: post #14

throwawaymath wrote: post #5

This is not a good idea, as implemented. You shouldn't disallow a user from using an otherwise strong password just because it's detected in a breach unless you can definitively see that it's already associated with their email address or username. The logical conclusion of a password checking system like this is that this password: ZBjHWJd$8XbJhY7LQvkmARBW)p7xgiDzDw}iMLLw can no longer be used by anyone, because I'v…

The odds of a user randomly selecting that password, rounded to 20 decimal places, is 0.

That's a fair point. My original problem with this is that you'd likely not have the entire copy of breached passwords available for local comparisons. But Troy Hunt provides that freely so you don't need to use his API. That wouldn't have much latency at all...that fact in combination with the obvious probabilities involved here, yeah I'll concede the point.

Re: Prevent users registering with passwords from data breaches

#107

Post by ss248 » Sat, Jan 19, 2019, 2:35 PM UTC

hombre_fatal wrote: post #100

ss248 wrote: post #86

Earlier quoted context omitted.

>Why wouldn't they be? Because it's trivial to implement decent ratelimiter which stops attackers, but still allows normal users to login.

That you must mitigate the attack is a direct point in my favor and a contradiction to yours: "nobody bruteforces the login pages in this day and age". It's also not a trivial issue. It's cheaper and cheaper to attack a website with unlimited IP addresses. Which dimension are you going to rate-limit?

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 evidence to suspect that account is under attack (like you see multiple low level of trust attempts with random ips) you limit the rate even more, with something like "no more than 10 low trust attempts per hour". If you allow to bruteforce thousand-entries password dictionaries in the reasonable time frame, it doesn't mean the "bruteforce problem" is not solved, it just means that your system is defective.

There is no lock that cannot be lockpicked. The only difference between a good lock and a bad lock is amount of time it takes to lockpick it.

Re: Prevent users registering with passwords from data breaches

#108

Post by hombre_fatal » Sat, Jan 19, 2019, 2:54 PM UTC

ss248 wrote: post #107

hombre_fatal wrote: post #100

Earlier quoted context omitted.

That you must mitigate the attack is a direct point in my favor and a contradiction to yours: "nobody bruteforces the login pages in this day and age". It's also not a trivial issue. It's cheaper and cheaper to attack a website with unlimited IP addresses. Which dimension are you going to rate-limit?

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 /login. It also shows how hard of a problem captcha is that you can't just roll it yourself.

You're still not addressing the problem since IP addresses are so cheap. I only need 1,000 IP addresses to try the top 1,000 passwords in parallel no matter what your rate-limit scheme is unless you plan on letting me lock the authentic user out of their own account.

You've wandered from your original claim that bruteforce doesn't even happen these days, and I'm certainly not saying we are helpless against it. In the end, I'd simply suggest that this problem is harder than you originally gave it credit for, and maybe that's something we can agree on.

Re: Prevent users registering with passwords from data breaches

#109

Post by bartread » Sat, Jan 19, 2019, 2:54 PM UTC

hannob wrote: post #73

All 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..…

Tend to agree on third party dependencies. They're a useful leg up if you're just prototyping, testing an idea, or generally groping around for product/market fit, but I'm not in love with them as a long term solution - certainly not for anything that's core to your product or service.

Too many potential pitfalls:

- If their service goes down, you may go down too, or you have the added complexity of gracefully handling the situation when they're down

- You have no control over their roadmap... which means you might suddenly get a bunch of non-value-adding but totally essential work dropped into your backlog, and perhaps at short notice, because of changes they make

- Perhaps they go out of business or, for whatever reason shut down their service: again, congratulations, you've just got a load of work you didn't bank on getting in the way of delivering your own roadmap

I think most of us have probably seen multiple examples of the above, if not at first hand, then posted on HN or elsewhere on the web.

I'm not an NIH kind of guy but I do tend to prefer libraries, or co-located installs for long-term dependencies. That way at least you can manage migrations and updates according to your own agenda rather than somebody else's.

Re: Prevent users registering with passwords from data breaches

#110

Post by scarhill » Sat, Jan 19, 2019, 3:10 PM UTC

rmtech wrote: post #34

Just a quick point that is worth considering: If a user types in a password and that password appears once in the HIBP breach list, then it is extremely likely that the source of the password in the breach list IS that user. If it appears 2-3 times, then there is still a significant chance that that user is the source of the password getting into the HIBP database. And if that user is the source, then the bad guys mo…

Exactly. I think of the HIBP password list as having three types of passwords (this is an oversimplification, but bear with me):

1) Extremely weak ones that lots of people use (e.g. 'password1') 2) Somewhat unique ones (their pet's name and birthday) 3) Truly strong ones (random, long strings)

I don't want users on my site using type 1 passwords at all. If a password is really type 3, the odds say that no user will ever try to use it again, so there's no collateral damage in blocking it. The person signing up with a type 2 is almost certainly the same user whose credentials are in the breach. I don't want them to reuse that password on my site because it makes their account vulnerable to credential stuffing.