The worst part of password rules is that every site has its own.
One requires a symbol, another doesn't allow symbols. A third requires 12 characters, a fourth only allows 8.
And they only tell you the rules when you're creating a password. They could at least remind us of the rules so we could remember how we had to mangle the password to match.
Or sites that require at least one symbol, but then mysteriously disallow a handful of common symbols (e.g. I used a site the other day where exclamation points were not allowed). Makes password generators like 1Password's useless about half the time, since 1Password rightly will pick from all (most?) common symbols on a standard US keyboard.
And of course, why would the site tell the user of its obscure symbol requirements before the user tries to enter their brand new password? No, I guess they think it's better to leave it at "a symbol is required" and then reject symbols users use one-by-one.
Password Safe[0] allows you to define a custom symbols list, for each entry. Not that this particular feature is worth switching over for, but just want to point out that it's not a limitation for all password managers.
The length requirements are logical if they have reasonable minimums and very high maximums.
It doesn't make sense to limit special characters, etc. Especially as everyone should be using a password manager anyways. I suspect most of these odd requirements are a result of design by committee and pointy haired bosses. Maybe requirements from legal departments?
As long as the annoying requirements are in place, we might as well try and get password mangers to work with them.
LastPass has a generator which can be manually configured, but making the step automated would be helpful.
What does "very high" mean here? And why would you need it? Usually, you just have a maximum request size in the web server, and people are never going to hit that with actual passwords.
Algorithms like bcrypt may have a maximum supported length: for bcrypt, over about 50 characters and things get dicey [1]. If you're running something computationally expensive like scrypt tuned properly, you don't want malicious entities to be able to send you a 32K password request, probably - easier to force them to keep it small (like < 50 chars), then block them based on request throughput.
Few sites silently use the first n characters and discard the rest, without any error. You find it only when u try to login.
India's pension system (kind of similar to 401k, you contribute monthly, you get pension monthly after 60) (eNPS (national pension system))[https://cra-nsdl.com/CRA/] does this. At initial signup, it helpfully tells max length is 14 chars. You need to change password every 3 months. So, i added a 1 behind keepass generated password. It said success. Error at login. Somehow i tried with earlier password. It went in, but said change password as its 3months old.
Your average developer considering allowing UTF-8 is going to weigh the cost benefits of unicode normalization vs. just forcing the user to use the lower ASCII code page and is going to opt for the lower ASCII code page.
If you are randomly generating the password anyways, I'm pretty sure allowing full UTF-8 will decrease the entropy since there are more wasted bits. I could be wrong, and I am too lazy to run the computation at the moment. Moreover, a randomly generated UTF-8 password will almost certainly contain characters that are difficult for the user to type.
I'd guess that this might be an attempt (perhaps misguided) to prevent people from using characters that they won't be able to type on some devices.
For example, on Mac I can easily enter Unicode from the keyboard by enabling hex unicode input (at least for Unicode up to U+FFFF...have to use surrogates to get past the BMP).
On my Windows desktop there is a similar option, with one annoying limitation: it requires using the numeric keypad. That's fine on my desktop system. It has a keyboard with a numeric keypad. It sucks on my Surface Pro 4. Both the real and the virtual keyboards there lack a numeric keypad. There are other options for Unicode on the SP4, but they are quite annoying.
If the site is an audio or video streaming site or a social media site or a photo sharing site then they might also be worried about people who will want to use them from their TV, A/V receiver, cable box, DVR, or Blu-ray player, all of which nowadays often provide network access and apps for various media services and social media sites. I don't think any of mine have a way to enter arbitrary Unicode from their clunky on-screen keyboards.
Speaking of TVs, cable boxes, etc., I wish sites would think more about those when setting password requirements. It is often cumbersome and slow to switch between lower case and upper case, or between letters and punctuation, or between alpha and numeric when using an onscreen keyboard via a remote control when all you've got is up/down/right/left for navigation.
I'd rather use a 21 character password using [a-z] or a 29 character password using [0-9] than use a 16 character password using, say, [a-zA-Z0-9!@#$%^&+:;].
Best, though, is to make it so you don't need to enter passwords on these devices to pair them with your services. I don't remember which service it was but I've seen one that handled it something like this.
1. You go to the website for their service and log in. On the website you can tell it you want to enable your account for their app on your device, and you give the device model and serial number. The website gives you a temporary PIN.
2. You go to the device and tell their app you want to enable your account. The app asks for the PIN then talks to the web service. The app and the web service can then set up everything for you.
What's the worst is when they tell you the rules when you try to reset the password, and then you know what your password probably was, but a) they won't cancel the password change process, and b) they won't let you reuse the old password.
I have also submitted a password reset to determine the password requirements so I could go back to login form and guess my password without resetting it.
I'm not sure this is a bad thing. You should have a different password for each site anyway, so the fact that it disrupts your ability to reuse passwords is an accidental pseudo-feature.
A different policy is unlikely to inspire a burst of entropic creativity in a chronic password reuser. At best, it changes _rover_ to _r0ver_. But you're right that some change is better than none, even if it won't stop a determined attacker who's fixated on a specific target.
Inconsistent plaintext processing is cause for special glee as well. My three favorites are strip(), substr(s, 0, 8), and tolower(). Nothing quite like manually brute-forcing your own passphrase to restore confidence in your ability to type.
If you include 1 uppercase, 1 lowercase, 1 number and have at least 8 characters, you should meet the password complexity requirements of most servers.
No. 8 characters is too short - no matter if you add in special symbols and upper/lower case. It's too easy to brute-force crack. You need something longer. And once you make it longer, the extra alphabet size from upper/lower case and symbols matters less.
It probably should, since it would mean that the site isn't hashing passwords with even the most ancient cipher. Bonus ineptness points are given for not using a prepared statement or sanitizing the SQL query.
As a software developer, I'm okay with that being criminal negligence.
In the US, the "Computer Fraud and Abuse Act" could apply. The case would revolve around "intent".
Explaining to interrogating officers that you hated password forms and wanted revenge would be 1 to 5 years in federal prison (better than state). Explaining to interrogating officers that you accidentally copy pasted wrong - the case would be dropped. This is why you need see a lawyer always before answering questions you will be mislead.
Apple iTunes/Apple ID pwd rules is really annoying.
Microsoft online service incl (based still on the decades old 1997's Hotmail login system is archaic) has an upper limit of 8 (or so) chars. (Office365/Outlook.com/etc)
Aren’t this the correct quotation marks? " means inch or seconds and is only used because most keyboard layouts make it hard to type the correct quotation marks.
The amusing thing is that we never care about this distinction in handwriting. "Oh, your two tiny vertical-ish lines denoting 'inch' are not ever-so-slightly slanted..."
In my handwriting, all quotation marks are pretty heavily slanted. That doesn't mean I would consider them distinct from hypothetical vertical marks. Fancy quotes are a display choice, not a distinct glyph.
> " means inch or seconds and is only used because most keyboard layouts make it hard to type the correct quotation marks.
I thought it was used because 7-bit ASCII had only 128 code points in which to fit all teletype controls, letters, numbers, and punctuation marks and symbols. They had to use each code point efficiently, and the ASCII double quote can be used as open quotes, close quotes, seconds, inches ... they also needed to support some European alphabets and therefore some punctuation marks, such as the single quote, double as accents when overtyped (using teletype control code points) on a letter.
So? Most symbols are 'unnecessary'. I'm pretty sure we could get away without ^ | # @ ` { } [ and ] for example. Hell Ancient Greek didn't even have spaces.
I distinctly recall seeing somebody post a comment a few years ago -- I think it was here on HN, though I'm not sure -- to the effect that they had used a line from an obscure poem in Afrikaans as a password, and it was cracked. -- Oh! HN Search comes through for me: here's a recent HN comment [0] by someone who also recalled it, with a link to the original [1].
I referenced this article today at work involving a discussion about password security, 2FA and actual customer experience.
Tonight I was dealing with Wells Fargo for a password reset. They have a max of 14 characters and a generally awful interface. I took screenshots of the process to use as a guide of things to avoid.
I had an idea for a website password system: instead of letting the user set a password, you just give them one. Prevents password reuse, which is the only thing that ever really commonly gets anyone's account hijacked in my opinion.
Doesn't even have to be strong, could be one word from the top 10k English words. Require reset after 5 failed attempts.
Would there be anything wrong with this approach (besides being sort of user-hostile), or have I misunderstood the website account security threat model?
A 1 in 2000 chance of correctly guessing someone's password could lead to lots of attempts which at best would cause lots of password resets and at worst cause lots of compromised accounts.
Yes. Using diceware (with actual dice) is still the most reliable way for a normal person to create a strong password. Use diceware. Ignore this guy's bad advice.
Our university forces us to change the password every 150 days. It is such a pain in the s, because there are too many apps on too many devices need to update the password. I asked the IT department, can you guys consider to stop this and find an alternative security policy? The answer is no, because this security policy is in the state law.
If you're really hellbent on it, you can probably tell the IT department they are full of shit and ask for the citation to the state code number - I am no state code scholar, but I have never heard of anything like this. In the NW States I am familiar with I could not find a single code section that even remotely touched on passwords at state schools. It would be an odd thing to legislate. Some states are goofy though.
I work in the public sector in Denmark. Here three months is required by law.
It's caused our most common passwords to be things like Summer17 and half the employees that actually use what they think are hard random passwords end up writing them down.
If you look under the keyboard if 100 workstations you'll probably find 10 passwords on post-its.
It makes little sense too because if we're compromising for 3 months we're probably going to be just as fucked as if we were compromised for 4.
The best policy we have is locking people out after 3 wrong attempts.
Duh. Obviously. And not like it's secure either. THe worst part is some sites ask you to change your password every month/3months/etc. That kinda sucks.
Kelvin is not expressed in degrees; it's just "Kelvin". Now to really throw people for a loop, tell them to do it in degrees Rankine (even less people know what that is).
Have his rules even been proven to be right? There's that famous xkcd comic about passwords and password strength checkers like https://howsecureismypassword.net that seem to imply otherwise. Short passwords with symbols seem easier to crack than longer ones with words put together a human could remember.
The rules, if used properly, work perfectly. But using them properly is burdensome, which means most people get lazy and the result is insecure passwords.
There are about 95 letters, numbers, and punctuation marks and symbols. If you choose a 12 character random password, it's uncrackable by brute force. The problem is, few people want to choose and remember a 12 character random password, and fewer will do that for each of the dozens of passwords they must use, so they choose insecure, non-random passwords.
Right about what, specifically? Being random is good. Being short wasn't part of the rules. Rotation is pretty bad. And words don't fix the core problem of making a good password because people love picking non-random words.
In general, every two random characters is worth as much as one random word. I personally find it as easy to remember three random characters as a word, so I get better mileage out of random characters.
Rotation is great if it's implemented correctly. The problem is that it's too much of a burden on users, therefore they implement it poorly, and then it's less useful or a weakness.
Rotation makes people pick things like Winter2017 or write it down, and it offers little safety because being compromised for 3 months isn't that much better than being compromised for a year.
