Hacker News Reader

Comment by pervycreeper | Hacker News Reader

Unfortunately, many sites enforce arbitrary restrictions on admissible passwords (e.g. between 8-13 characters, at least one digit, one lower case, and one uppercase). This makes the whole proposition much harder. I wonder if there is some purpose behind this (make things a little harder for the small-timers, but open the doors for the big guys).

View on HN

Banking sites seem to be notorious for this. The worst offenders will simply truncate the password, too, leaving you to believe you're using a much more secure password than you actually are.

This is absolutely the case with USAA. No warning whatsoever was given that they truncated my password which led to me being locked out when it autofilled from LastPass. I contacted them but all they've offered to do is "forward it to our security team".

for a long time one of my credit card companies truncated my password. I typed in something long and hopefully secure when i set my account up. Something like "NineteenBumblingElephantsOnP4r4d3". I didn't even notice it was truncated for a while because whenever i typed it in the form would just stop accepting characters after 8 or 10 which is what the original sign-up form had done so I was still entering the correct password but it was shortened to "Nineteen" Not a very secure password at all.

I still think that the standard should just become a 100-200 characters password limit with no other restriction. That way the majority of user can just use common long sentence (music lyrics, event) as their password. I know the password cracker supposedly will include those into their database eventually. But I have trouble believing that adding a whole sentence in a lyric (ie: thisisasongtwinkletwinklelittlestar ...) will have lower entropy then whatever arbitrary restriction to add a special character (ie: thisisasong!@#$) would be. Ordinary user does not use Unicode in password, and I'm not even sure if half the password system out there won't break with unicode password. It seems like since we're sticking with Ascii, length almost universally add entropy, isn't it?

Why an arbitrary 100-200 character limit?

"I still think that the standard should just become a 8-16 characters password limit with no other restriction."

Anything much over a kilobyte has zero benefit and has potential to cause issues or slowdowns when shoved through a path that expects a short string.

It's very doubtful you'd type such a crazy-long password by hand, and if you have a password manager there's absolutely no reason to go beyond something like 256 bits of noise encoded as hex.

I like the "We have a list of the top 10k passwords. You can't use one of those." rule.

>common long sentence

Oh god no. Don't use a common sentence as the majority of your password. Don't try to be more clever than the password cracker. It's easy to get lists of common sentences and lyrics. Sure, a common sentence is better than a single special character, but it might only be as good as 3-4 random characters.

Assume the cracker knows your method, and go based on an estimate of entropy. So perhaps a random character is 6 bits, a random word is 12, and a common lyric is almost certainly between 20 and 30. Keep adding things until you have 80 or 100 or 128 or whatever your goal is. (I would strongly recommend not using 44 as your goal.)

I just want to clarify the point about long common sentence: we keep getting stuck with comparing 100 characters commoN sentence with truly good password from rng. Of course the latter is far better, but the average user is not going to use RNG to generate password. The comparison is between common long sentence against 20 characters password with arbitrary restriction.

20 characters where the user attempts to be random is going to be much better than any common sentence.

Even 10 characters of attempted random is going to be better.

Maybe even 5, if they were going to use a song everyone knows.

Increasing the minimum size past a point doesn't help security, it just leads to people using low-entropy padding methods.

Whether a sentence is better than "no restriction", I'm not sure, but that's not a very fair comparison because you can't force them to use a sentence either.

I'd say what you should recommend is a series of words that don't make a sentence, but where they can remember a scenario.

Or you could have the computer generate random words and let them make a sentence out of them.

But don't use a preexisting sentence, or a tiny modification to one. It will be far weaker than it should.

Absolutely. The result of these policies leads to, from my experience anyway, trivial but very difficult to remember passwords that end up getting written down or reset every time the user attempts to log in to the service.

That being said, I find passphrases hard to take on myself. I tend to use a set of mildly complex passwords I've used for years across a number of services.

Apparently the new key to passwords is a secure password db that you only keep a master key to access and then paste the passwords contained into services as needed. I've given a few of them a try but even then personally I'm not comfortable having my passwords kept on an external service, even if I have the master password to myself.

You can use KeePass http://keepass.info/ instead and keep the master database yourself. If you want sync, you could use an external service, or just copy/sync files yourself, or use a USB key.

There are some sensible restrictions:

You can't enter certain characters in input type=password fields on web sites, such as null or CRLF

Max length for bcrypt is 50-72

Incredibly long passwords could DOS your site

>Incredibly long passwords could DOS your site

They don't need to permit arbitrarily long passwords, just ones that are long enough.

Well you asked about arbitrary restrictions... :)

Fair point. :) Although, in the first instance, I had meant `arbitrary' to mean something slightly different, more along the lines of `a condition chosen without adequate justification', rather than `permitting anything whatsoever', as in the second.

Reply on news.ycombinator.com