3 ms·
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
by air7 8y ago
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 happen, they are very infrequent events. But once they happen, you should assume all passwords would be cracked very fast. Hackers can get their hands on a lot of computing power, and the brute-forcing attempts are not alphabetical, but rather clever how-humans-chose-passwords models. You're relatively safe because of the low frequency of breaches, not because a hacker trying trillions of passwords a second will be frustrated by your password choosing policy. I'm sure most of the passwords from the breaches would be attempted anyway.
Credential stuffing[0] is the real issue. If there was an API to test that a user isn't using this password on other websites, that would be very useful.
[0] https://www.owasp.org/index.php/Credential_stuffing https://www.owasp.org/index.php/Credential_stuffing
- hombre_fatal 8y agoOur 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 reuse is a massive issue. At a glance, one might wonder why most sites need to care so much since they don't deal with money. Who cares about a forum like HN? But consider that it's easier to audit/impede new accounts with anti-spam measures, so there's value in taking over old accounts. And you don't want people with moderation tools getting attacked either. Ideally, it's nice to be able to trust an account with 1,000 posts more than one with 0 posts, but that evaporates when accounts are easily stolen. Aside, how do you implement account-locking without making it trivial for users to DoS each other that way?
- air7 8y ago> 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.
- hombre_fatal 8y agoWell, 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".
- air7 8y agoSorry, 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.
- ss248 8y agoYou're right. I don't know why it's still not a common knowledge that nobody bruteforces the login pages in this day and age. But I guess too many people, who have products to sell, benefit from the status quo, so things are not going to change.
- hombre_fatal 8y agoNo, login pages are definitely "still" brute forced. Why wouldn't they be? It's easier than ever.
- ss248 8y ago>Why wouldn't they be? Because it's trivial to implement decent ratelimiter which stops attackers, but still allows normal users to login.
- nsgi 8y agoJust because it's trivial doesn't mean all websites are doing it.
- ss248 8y agoSome sites store passwords as plain text. And? But if care about security, you might as well solve the problem properly instead of wasting your time implementing "your password must have a capital letter and a number" snake-oil features which only annoy your users.
- hombre_fatal 8y agoThat 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?
- ss248 8y ago
- spacehome 8y agoI'm not so sure about that. Hire time on a botnet so you have lots of IPs and start trying mixed usernames with mixed passwords. You won't have any choice over which username you eventually break in with, but I don't think you'd trip any alarms either.
- epriest 8y ago> 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/ https://github.blog/2013-11-20-weak-passwords-brute-forced/
- scarhill 8y agoMaking 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.