5 ms·
You are not forced to use 8 only on most places. And most of the time 8 is good enough. And by forcing more characters you may end up messing things up because
by henvic 10y ago
You are not forced to use 8 only on most places. And most of the time 8 is good enough.
And by forcing more characters you may end up messing things up because people can start using patterns that defies the very core idea why there should be a 'minimum length'.
And rate limiting (see 5.2.2) should take care of most concerns about it.
Though, I think this is bad
> Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period.
Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.
- cstejerean 10y agoThen consider this a rate limit with average of 3.3 attempts per day over a 30 day period.
- henvic 10y agoExcept this is a rate limiting on the account globally, and here lies the DoS problem. So if you follow it you can theoretically have your account locked down by an idiot on the other side of the world. You can minimize this by making it per IP, for example. So, you'd have to have an idiot on your home. Yeah, maybe this is not 100% bullet proof given IPv6 and so on, but at least this doesn't introduce a vector for DoS.
- Spooky23 10y agoYou mitigate that by putting MFA in front.
- kbart 10y agoMFA is not a magic solution to all problems either. You can't expect me to give my phone number or real email address to every random site I login into.
- petters 10y agoA security key should work.
- CiPHPerCoder 10y agoYou don't need to do that for HOTP/TOTP though. 1. Scan a QR code. 2. You now have a secret value that can generate a deterministic pseudorandom integer securely indefinitely. Also, SMS-based MFA should be burned to the ground.
- AstralStorm 10y agoScanning a QR code by hand is easy when you don't have the phone handy. (sarcasm) Actual OTP should allow you to print out or write down a set of codes.
- CiPHPerCoder 10y ago> Scanning a QR code by hand is easy when you don't have the phone handy. (sarcasm) That's way different from "I don't want to give out my phone number".
- user5994461 10y agoBoth are impossible when not having a phone.
- CiPHPerCoder 10y agoIt's non sequitur. "I have a phone number but don't want to give it out" is different than "I don't have a phone". But hey, there are 2FA devices you can use instead.
- jon-wood 10y agoThis is why I'm a big fan of the U2F standard, which allows a device (generally a small USB/NFC device) to generate shared secrets for arbitrary services without exposing any personal information.
- sh_tinh_hair 10y agoMFA is basically another key|password. If I am not careful with my secret key and password what difference does it make that there are two of them? No, security is tough. The better security the less useful it is. NIST got this right. Do what you can, don't kill the user and implement security on the aaa side.
- Spooky23 10y agoHave you ever messed with a friend by locking out their phone? I was specifically addressing the DoS vulnerability of locking an organization out en masse by taking advantage of account lockout or timeout policy. A list of emails and a six line script could take a whole company offline. MFA can be used to address that by requiring pre-auth before you can enter a password.
- mulmen 10y ago> Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single I think that can be read two ways. 1) 100 failed attempts/account/month 2) 100 failed attempts/IP/account/month The latter still limits an attacker but is less likely to be a plausible DoS against the account unless the attacker has compromised the legitimate user's machine at which point all is lost anyway. Later in the same section: > When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts from the same IP address. Which suggests the failure count is per IP and not per account.
- gohrt 10y agothat part is saying that once an IP gets a password correct, don't count past mistakes against them.
- jakobegger 10y agoRate limiting per IP is close to useless, since it is trivial for an attacker to attempt connecting from different IPs.
- thomasahle 10y agoHow trivial is it? Would an attacker wanting to do one million attempts easily be able to send each from a different ip?
- eli 10y agoBad guys can easily rent time on botnets with hundreds of thousands of ips.
- henvic 10y agoSo the solution for you seems to be allowing bad guys DoS your system because bad guys can do bad things, is it?
- jessaustin 10y agoIs per-IP rate limiting the only one way to respond to auth DoS? Different situations involve different trade-offs.
- eli 10y agoRate limiting. Not denying service. Bad guys could cause you to have to wait some number of seconds to log in.
- vidarh 10y agoMost of the time when I see large scale password cracking attempts against customer servers, I have to block large blocks because they're coming from large number of IPs. I had to block most of South Korea at one point, because we saw abusive traffic from millions of IPs belonging to a couple of major ISPs in South Korea (thankfully non of our customers had much if any legitimate traffic from outside Europe at the time). So the answer is: Some are already doing that.
- iopq 10y agoRate limiting seems like a good application of neural networks. Find out when hackers tried a lot of passwords and when users tried a lot of passwords. Run that data through a model and you can get a model that changes as hackers change their attack methods. Although you'll have to manually classify hacking attempts vs. real users.
- Spooky23 10y agoRate limiting is better than lockout. Other federal agencies (IRS in particular) require lockouts with only 3 bad password attempts. That generates really high reset/unlock call volume -- easily 20-30% of users require intervention or reset compared to 7-12%.
- mulmen 10y agoCan you explain those numbers? 7-12% of what? Are you suggesting that rate limiting reduces call volumes by a little more than half compared to lockouts? Where did you get the data?
- ajkjk 10y agoI think s/he's saying that rate limiting leads to fewer password resets compared to lockouts. Which makes sense.
- Spooky23 10y agoIn one large, diverse environment I'm familiar with, that policy spiked the need for intervention (password resets, unlocks, etc). That spikes costs. Many users (mobile) need to call someone, which is $$$. Those interventions also lead to things like figuring out what app stored password is relocking the account. That kind of exercise could cost a few hundred bucks. ...all for zero benefit.
- rrobukef 10y agoHeh, I often have more than 3 wrong password attempts. Lockout is a really bad idea for me.
- richmarr 10y agoContext is also relevant. The iPhone for example has a PIN lockout, and young kids love phones. More than once I've been punished by Apple for my kids curiosity.
- 10y ago
- semi-extrinsic 10y ago> This is prone to a DoS attack. When will we see the first organization (government or private) that is effectively completely DoS'ed for days on end because their login does this, while all their email addresses are listed on their website? If sustained, I imagine this could shut down an entire organization quite effectively for a few days. Probably could lose someone millions. Or add insult to injury, and have them pay BTC for the attack to stop.
- jessaustin 10y agoSuch an organization might investigate the use of stored tokens so that all users don't have to be authenticated simultaneously.
- henvic 10y agoSometimes I definitely scare my coworkers just by caring about such edge cases. They probably think I use foil hat at home :)
- johnward 10y agoWhen I am limited to only 8 characters it's always a bank account.
- mathgeek 10y agoI've found the best way to get around this limit is to give the account information to my payroll department and then never access it.
- JadeNB 10y ago> I've found the best way to get around this limit is to give the account information to my payroll department and then never access it. Maybe I don't understand, but isn't the issue not your access to it, but others'? If you are forced to have a weak password protecting sensitive information, then it's an issue even if you never need to access that information yourself. (Or maybe you mean that you never even establish the account, and hence the weak password, in the first place?)
- mathgeek 10y agoMerely wordplay on leaving your money in an account and letting it accumulate. Was continuing on the "8 character limit in my bank account" double meaning.
- eriknstr 10y ago>rate limiting (see 5.2.2) should take care of most concerns about it. Not in the case the hashes are leaked. However I agree very much with what you said otherwise.
- bo1024 10y ago> Though, I think this is bad > > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period. > Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another. I agree. Nobody is going to guess a good password in 100 attemps, or 100,000,000 attempts. A tiny bit of rate-limiting, like one login attempt/second, should be enough to prevent successful brute force on good passwords. The threat is hacking the database of hashes and brute-forcing offline.
- samirm 10y ago8 is nowhere near good enough.