Live data from Hacker News

I hate password rules

schneier.com

321–330 of 447 posts

Re: I hate password rules

#321

I used to have those: 8-24 characters among which 1 uppercase/lowercase, 1 special character among a whitelist, and renew that every 2 months. At renewal, must be different from all your previous passwords and the new password must be at least 3 character different from last one. SSH keys can't be used per security policy and the same rule has been applied to the password manager. A pain. And yes the most annoying is…

Not many places will try a brute force attack directly on a login interface, but if your database is leaked the definitely. Nothing to rate limit an attacker then

Re: I hate password rules

#322

Earlier quoted context omitted.

I think even if you were fired, you'd have dodged not a bullet but a cannonball there. Sometimes being the nice guy full of good faith doesn't pay. Literally

Nah, I worked there for a long time and I was sad when I needed to leave. I had best boss and best project ever and I learned and grew a lot.

That's good to hear! Although I would have been frustrated and made anxious by their security practice. Did they change their security practices after that 'event'? And did you manage to regain access to your development box?

Re: I hate password rules

#323
post #266

My frustration isn't just the sites that make the password rules clear after I submit the form. The worst sites are the ones that truncate my generated password to fit their maximum password length and then don't tell me (which seems to happen in more places than it should).

Worse: I once set my E*Trade password to something it accepted but wouldn't recognize when I tried to log in… because it was too long. After changing it I got locked out of my account and had to call support to resolve the issue. The worst part was that after verifying my identity over the phone they kept sending me reset links and I kept using long passwords generated by 1Password (30 characters IIRC) and it always…

It gets worse: if you use 2fa the security code generated by the symantec thing is just appended to the password, so if your password is still a valid length, but then the 2fa takes it over 30 chars, it fails. It is the worst.

Re: I hate password rules

#324

NIST best practice recommendations state: * Require more than 8 characters * Don't require special characters * Don't force the user to reset their password * Do check for compromised passwords * Require MFA * ... All very sensible. https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...

Why do basically zero companies seem to follow this? Banks and airlines are of course some of the most egregious offenders, but even tech companies like Apple and FB have complexity requirements on capital letters and numbers. Surely the login security teams at these companies are aware of the NIST recommendations. Yet a tiny 3 person startup launching a simple crud app is more likely to google the NIST requirements…

NIST standards are technical guidance. The issue is downstream where different authorities make policy based on whatever NIST said at one time.

If you need to interact with taxpayer data and interact with the IRS, for example, you’re required to comply with fairly prescriptive controls for a variety of things that conflict with current NIST guidance.

The other thing is that changing anything identity is a pain in the ass. If there’s a business process and outsourced support model in place to deal with account issues, it’s actually easier to just deal with the shitshow than to fix stuff. Big dumb organizations make decisions differently!

Re: I hate password rules

#325
post #242

A few years back, not too long ago, I started working on a new contract assignment at a medium size aerospace manufacturer. I show up and check in with IT department. The system administrator shows me to my desk, and hands me a post it note with my password. Well pass phrase is more like it. It was something like “sliding down the tall building”. I was quite impressed that they encouraged the use of long pass phrases…

Pro tip: When you're seeing something really unethical that could eventually rebound on you - write it down. Write down contemporaneously what happened and sign and date it. Much more reliable evidence.

Send it in an email too. "Hi IT guy and Boss, I'm concerned about blah, but understand people need access to everyone else's computer and account. Yada yada." Don't be difficult, but get an email out there with a time stamp on it and forward all that to your personal account if you can.

Re: I hate password rules

#326

Earlier quoted context omitted.

I have multiple financial accounts that still insist on using public-knowledge security questions (which of course I've given fake answers saved in my password manager) instead of just letting me set up proper 2FA. It's infuriating.

Yeah, my bank does that too. Asks for my birthday for "security" reasons. They also kill their website's usability by forbidding physical keyboards and forcing users to use a virtual keyboard with randomized key layouts in order to type passwords in a feeble attempt to defeat keyloggers. Some banks even make it extra annoying by generating ambiguous keys like "1 or 7" or "2 or 3". The saddest thing is banks can't be…

I imagine it also disables autofill from password managers (since it's not actually a form field)?

I would literally close out my account in that very moment if my bank did that. Not only because that's horribly inconvenient and I would never put up with it, but it also shows they have no idea what are sane security measures or not.

Re: I hate password rules

#327
post #143

Earlier quoted context omitted.

Anything requiring my phone number or a binary that runs on my phone is a deal breaker for me. It has massive privacy implications. We desperately need to have better MFA options if we're going to require it from users.

> or a binary that runs on my phone is a deal breaker Phone numbers, fair enough, but TOTP is an open standard and there are plenty of open source implementations for the client side. It’s also available in most password managers (I use 1passwords implementation). “MFA can’t require me to run a binary on my phone” is a bit extreme. TOTP is fine.

TOTP doesn’t meet the security requirements of higher trust level auth. You’re demonstrating why - storing your MFA with your first factor is pretty dumb.

Where I work a bunch of people had a cow about having to put a MFA app on their phones, but refused to take a work phone. Our remedy was to issue them PINs to allow after hours access to the building.

Re: I hate password rules

#328
post #251
post #242

A few years back, not too long ago, I started working on a new contract assignment at a medium size aerospace manufacturer. I show up and check in with IT department. The system administrator shows me to my desk, and hands me a post it note with my password. Well pass phrase is more like it. It was something like “sliding down the tall building”. I was quite impressed that they encouraged the use of long pass phrases…

On the plus side, it also gave you plausible deniability it really was you if you wanted to do something illegal or unethical.

chaotic hysterical

Re: I hate password rules

#329

Earlier quoted context omitted.

This level of negligence should be criminal.

The software industry is full of should-be-criminal forms of negligence. Things are already horrendously bad. Basically every American's identity could stolen at this point. If any nation state or other actor decided to operationalize any of the big leaks -- eg OPM or EquiFax -- the ramifications would be catastrophic. Imagine millions of people losing their retirement accounts and all their savings. Even if you coul…

if that were to happen it would be a "to big to fail" event. the gov would bail everyone out and mandate a reset to what ever it was believed to be before. bank accounts, retirement accounts etc would be reimbursed up to the FDIC limit. credit reports would be rolled back to the last known good value. it would probably fuck things up short term but long term it would lead to better security of consumer data

Re: I hate password rules

#330
NIST 800-63B [1] has some good guidelines on password rules, one of them being low complexity:

"As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets."

[1] https://pages.nist.gov/800-63-3/sp800-63b.html

Post reply on HN