
Limiting passwords to 12 characters is "secure enough" - Jayschwa
http://forums.stardock.com/439802
======
kijin
If a 12-char password is "secure enough" today, then a 16-char password is
obviously even more secure and future-proof. Not to mention a 30-char
password, or a password that contains more special characters than what your
dumb webapp allows.

Not to mention that a 30-char purely alphabetic passphrase such as
xkcd.com/936 is so much easier to remember (i.e. less likely to be written on
a post-it note) and type into today's mobile devices (i.e. more likely to log
out properly, because it's easier to log in the next time) than a 12-char
password with two numbers and one symbol in it. What I'm trying to say is that
_there is more to password strength than the time it takes for a botnet to
brute-force it_. Humans are the weakest link in most security systems. If you
want strong security, you need to design your system so that humans can
interact with it without too much mental strain.

Nowadays, anything less than [\x20-\xFE]{8,64} is just a lame excuse for
storing passwords in a plain-text VARCHAR field without proper escaping.
Therefore, if your password policy as any more restrictive than
[\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-
text VARCHAR field without proper escaping.

~~~
cantos
Here are two real world issues that could arise

[http://vbuterin.blogspot.ca/2011/08/password-strength-
rebutt...](http://vbuterin.blogspot.ca/2011/08/password-strength-rebuttal-
to.html)

I think some cryptographers and security people have given rebuttals as well
but I can't find them at the moment.

~~~
kijin
Interesting, but I think the author is focusing too much on the desktop
experience. Try typing 'Tr0ub4dor&3' vs. 'correct horse battery staple' on a
phone. Having to shift between alternate layouts every other character is not
only annoying but also makes you prone to forget which character you were
trying to type. With a full-size keyboard, on the other hand, you can rely on
muscle memory to get it right without even thinking. As for shoulder surfing,
I find it rather difficult to shoulder-surf someone who is typing on a glossy
4-inch screen, and you can always choose unusual words/spellings to throw off
people who try to guess. Corrupt hearse buttery scalpels!

~~~
cantos
I agree that it would be a better system for phones. I'm not sure about full
size keyboards. Muscle memory will allow you to learn the password with only
simple characters more quickly but eventually both will be learned. Then the
only factor that matters is how accurately the user can type. I don't think
muscle memory could ever get 100% accuracy for typing one character correctly.
Anything less than 100% and longer passwords will be worse. If you type a key
correctly 99.9% of the time then you will lose about twice as much of your
time to wrong password entries with an 11 vs 20 char password.

------
jimrandomh
As I see it, character limits aren't so much about security, as just a dumb
way to be hostile to the user. All of my passwords are site-specific unique
passwords generated by a password manager. I don't care if you store plain-
text passwords, because if someone steals passwords out of your database then
they already have all the access that my password to your site would've given.

But if a site rejects the password that my password manager generated (16
chars [a-zA-Z0-9]), then I have to work around it, make a password manually,
and it's generally a pain in the ass that shouldn't be necessary. And since
I'm doing it right and these sites doing it wrong, I'm not inclined to be
forgiving.

~~~
izend
Isn't there research out there that proves long sentences and phrases are
better than any random alpha numeric password

~~~
DrJosiah
No. And preliminary research suggests that they are easier to crack.

[http://arstechnica.com/security/2013/01/grammar-badness-
make...](http://arstechnica.com/security/2013/01/grammar-badness-makes-
cracking-harder-the-long-password/)

Legitimately randomly generated passwords still win, as long as the server
uses a salt with bcrypt or iterated hashing like PBKDF1 or PBKDF2.

------
omni
Ah, yes, there's nothing quite like a condescending representative entirely
out of his depth telling you to "do the maths" to show your customers that you
really care about their security and privacy. I wish you good luck in getting
them to listen to you.

~~~
danielbarla
That entire thread was cringe-worthy. At least the last company I reported
something similar to came back with "our developers are looking into the
problem, and we will probably switch out the login scheme in the next few
weeks". Whether they actually did it or not, who knows, but at least they
acknowledged it.

------
yarianluis
This is far from the worst offender.

Banks are typically the worst. All sorts of gimmicky password requirements.
8-12 characters. Must have one capital letter. Must have one number. No
special symbols.

So "I can't believe it's not butter!" won't work, yet that would probably be a
pretty secure password, and be entirely rememberable. In fact I could come up
with a silly pun-filled sentence for each site I visit and make passwords fun
again.

~~~
Jayschwa
The poor state of bank passwords is fresh in my head from working on taxes
tonight. It's kinda sad that the message boards I use for non-sense are
probably more secure than my banks with respect to password handling.

That said, I don't think Stardock gets a free pass just because a lot of banks
suck at it.

~~~
yarianluis
Nobody gets a free pass. Didn't mean to imply that. They all suck, it's just a
matter of venting :)

------
sp332
Even if they were brute-forcing, a new GPU cluster can do 350 billion guesses
per second. [http://arstechnica.com/security/2012/12/25-gpu-cluster-
crack...](http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-
standard-windows-password-in-6-hours/) That means an average of 78 days to
crack an individual password, even with no heuristics about which passwords
are more likely.

~~~
lucb1e
The first step is to convince them that the database is not actually failsafe
if even companies like Linkedin can't do it. Then convince them that it
matters if the password leaks (you should use unique ones anyway, but everyone
knows that not everyone does). Only then this kind of offline brute-forcing is
an argument.

------
tlrobinson
When I complained to my bank about their 12 character limit they told me...

 _"12 characters is already hard enough to remember."_

Sigh.

~~~
UnoriginalGuy
I would have just responded - "You know 'Lord of the rings' the movie, right?
The title of that movie is a 17 character password. Is that hard to remember?"

~~~
kijin
It is kinda hard to remember if you need to pepper it with numbers and special
characters to comply with the bank's rules.

    
    
        L0rd_ofthe$Ring5

------
eksith
Get a whole heap of passwords from random.org. Create a text file with the
sites you use with the usernames/passwords. PGP Encrypt the whole ensamble
with a good strong password. The only one you really need to remember.

Forget your password? Once you reset via email, as soon as you get access to
that encrypted file, get a new random password and reset it again. Save the
new password in the encrypted file.

Password managers often connect to the internet to retrieve your passwords so
if you lose your access, you're SOL. I also wouldn't trust a browser plugin as
that may be prone to compromise. Backup to your laptop or something if you
need to take it with you, but keep it encrypted until needed.

Forget the password to the encrypted text file? Throw your life away and start
a new identity.

Edit: Pointed out below (and I agree whole-heartedly) use /dev/u(a)random

And idupree's points are spot on.

~~~
idupree
(my tinfoil hat mode: I don't even have any important secrets but I believe in
knowing how to protect them)

Use /dev/urandom, not a website. Make sure you have configured your text
editor not to automatically save any backup files, cut buffers, or the like,
and never write it to disk in unencrypted form. (I use vim >= 7.3 and its
blowfish encryption; see encryptedvimrc and random_alnum in my scripts
<https://github.com/idupree/scripts> ) If you copy/paste passwords, make sure
you don't have a clipboard manager that persists recent history to disk. Also,
encrypt your filesystem in case you screw up on any of the above. If you have
swap, make sure that's encrypted with a generated-per-boot-from-urandom key
generated after loading last boot's stored entropy from the disk. (A dedicated
password-managing program might do some of these things for you. I haven't
looked into their security methods yet; have you?)

If you can, use an email provider for your acct-registrations that uses decent
security practices; use a high-entropy password for it; use different email
addresses for every site, to make it harder for social engineering attacks
(someone calling, say, Amazon or Apple's call center pretending to be you).
The latter is probably hard unless you use your own domain or think '+'
addresses are sufficient. If you use your own domain, you're vulnerable to
your registrar or your account with them or your DNS being compromised, but
you should have rigorous passwords and good registrars here because losing
your domain name stinks. If malware gets on your computer, it can watch you
and steal your passwords, so keep your system and browser up-to-date with
security updates, disable riskier parts of your system that you can live
without, prefer OSes/systems that are more on top of their security, and don't
make enemies.

I don't understand why password managers like OnePass store passwords online;
everything else they're doing as browser plugins is fighting the good fight.
(True, there are risks of giving the browser the ability to access your
passwords at all; but they're probably less than the risks of password reuse
and low password entropy, and greater convenience means more people will use
the system for more sites. Firefox Sync is the only consumer-friendly online
storage that I've seen and consider well-engineered-&-documented enough to
consider trusting. Tarsnap and Tahoe-LAFS also meet everything but the
"consumer-friendly" bit there, and have a somewhat different focus. It may be
worth considering encrypted online mirrors legitimate (online _mirrors_ , not
sole copies) for the sake of people who don't do backups, have multiple
devices, and/or have their disk fail or device stolen.).

~~~
newman314
I think you mean LastPass or 1Password.

Startup idea: the email equivalent of 1Password.

You give each site a completely unique, distinct yet valid email address. They
forward to your real email address and vice versa.

This way if one email is compromised you know where the spam is coming from
plus it reduces email tracking and correlation.

~~~
KMag
At least the last time I used it, Google Checkout had an opt-in feature that
would create a unique unguessable email address the first time you purchased
something from a shop, and this email address would be proxied to your GMail
account.

~~~
newman314
While that is nice, I was thinking of a more distributed model (not
necessarily hosted by Google)

------
Jayschwa
Stardock deleted the thread after it started to get some attention. Here is a
partial screen capture: <http://i.imgur.com/R5gs8HC.png>

Unfortunately, it's missing some of the newer (and frankly, ignorant and
cavalier) replies from their tech support guy.

------
akg_67
Reading comments in this thread have been very enlightening. I am wondering if
there is a best practices or guidelines for password storage for web service
operators.

I currently manage a web service that has about 1,000 registered users. I have
taken the most restrictive path to storing password in database except I need
to make sure user/password database is portable from one host to another.
Reading the comments, I am getting the impression that such portability may
not be a good thing. But then how can I migrate from one host to another or
restore backups?

Are there documented good practices for storing passwords in database that
also allow portability.

~~~
jmspring
Simple rules for the bare minimum

\- never store plain text password \- never store direct hash of password \-
use a salt (must be stored) and hash password and salt

Ideally salt and hash of password/salt are in different databases.

Avoiding MD5 is recommended, but if you are at the point of worrying about
that, you have bigger issues.

~~~
UnoriginalGuy
I agree with everything you said except the "store in two different databases"
line. If someone has compromised your system responsible for handling
authentication then presumably they'd have access to both databases regardless
- unless you've designed some kind of complex API for generating the salt and
secured that API behind a whole different set of security and authentication
(which almost everyone is too lazy to do).

The salt is just there to stop rainbow tables being generated, and if you're
really evil to add computational overhead, it isn't meant to be used in a game
of hide and seek.

------
linhat
I'm not so sure anymore about the password length limitations (or any other
weird password requirements for that matter).

For the longest time I was wondering why my bank would ONLY allow a 5 digit
password, alphanumerical only and it MUST contain at least one letter as well
as one number, while they let you choose your own username completely free of
any restrictions, including special characters. After thinking about it for
quite some time, I remembered all these sites where your password had to be as
least 6 characters (now 8 seems to be a general minimum).

By forcing users to use EXACTLY 5 characters at least you cannot use the SAME
password your already using for your mail and whatnot, except for the fact
that there is nothing preventing your from simply dropping the last character
(but you sure would NEVER do that, would you ;-), assuming of course you
already have letters as well as numbers within the first 5 characters.

While 5 characters seems extremely weak, If you get it wrong 3 times, your
account is locked. Locked as in "you have to call them and identify yourself
with A LOT OF DETAILS about your account and transactions" to unlock it and
reset your password.

I have no idea how they store passwords and it doesn't really matter to me,
while it probably should. They are a BANK and if they get hacked and their
customer password database gets compromised, I am sure they will have worse
problems to take care of.

What I would really like to see is their evaluation of security versus added
support work for locked accounts.

~~~
KMag
You are incorrect. The policy is that users get locked out after 3 attempts...
until attackers get smart enough to bruit force through the usernames, 3 wrong
passwords each.

80% of the customers getting locked out of their bank accounts at 5 PM on a
Friday only happens once before the bank changes policies to something that
allows the attackers to perform a rate-limited attack on the 5-character
passwords. The new lockout policy goes into effect before the bank can force
everyone to upgrade their passwords.

GAME OVER

------
lucb1e
They deleted the topic. Nice way to treat your customers...

------
axelfreeman
Skype Passwordlimit: 12 Charakters. Windows Live Passwordlimit: 16 Charakters.
Paypal Passwordlimit: 20 Charakters. It's stupid to put this limit on
passwordinputs that should get hashed anyways. Twitter, Facebook, Google
Password Limit: >100 Charakters.

------
lucb1e
Added a rather lengthy comment, hopefully convincing them a bit. Let me know
if I should edit anything! My username there is the same as here.

<http://forums.stardock.com/439802/page/1/#3315302>

------
ck2
In theory it is secure enough - you should not be allowing a password attempt
every second on an account and unlimited attempts per day per account.

But of course we should be using pass-sentences by now.

~~~
omni
> I'm not concerned that someone is going to brute-force my password

Please read the article before commenting. The OP's concern is that all of the
passwords are sitting in plaintext in a questionably-secure database
somewhere.

~~~
ck2
I stand corrected, there is absolutely no excuse for plaintext passwords.

------
atsaloli
Bill Cheswick, of the "Firewalls and Internet Security; Repelling the Wily
Hacker" fame, gives a great talk called "Rethinking Passwords" calling for a
better solution:

<http://www.youtube.com/watch?v=KRVRlhrLKkI> [video, 22 min]
<http://web.cheswick.com/ches/talks/rethink.pdf> [slides]

------
Sami_Lehtinen
I blogged about week ago: Some funny stuff for a change: I told my colleagues
that we receive at least 5000 "hack attempts" aka failed logins daily to any
of our public Internet facing servers. One of my colleagues just said to me:
"Well, you're having such a ______password policy, that maybe those are
actually failed login attempts and not hack attempts at all." - It really got
me laughing. Yes, passwords, especially long complex and random ones are
painful for users. Here's password of the day (opening and closing quotes
aren't included in the password):"^j'lb#K-€3, <_úgWJdXå(n_6=41Bµ%cj!" Btw.
Good luck guessing the password or finding it out using SHA-1 hashs or so. I
know it's possible, it just might take a while. ;) p.s. This password still
got less than 256 bits of entropy. I never really intented anyone to actually
remember the passwords. I personally consider passwords as "shared secret",
which is just a blob of random bits.

~~~
engtech
Passwords have been compromised before by being captured in server logs that
ended up being accessible.

If you are logging failed password attempts anywhere, then you've got a
security hole.

Here's the details on the breach I'm talking about <http://ieeelog.com/>

------
jere
What about 5 characters? Saw this today on a product that claims "We use
advanced technology in a security–rich environment"

<https://twitter.com/humbit/status/297417037989429248/photo/1>

------
SideburnsOfDoom
I've seen worse. There's a UK company called The Train Line (
<http://www.thetrainline.com/> ) that handles money, and limits passwords to
10 chars with no punctuation characters.

~~~
tomd3v
I don't understand why you are so upset. Just edit the HTML and set maxlength
to anything you want. It will seal a deal. :D

~~~
SideburnsOfDoom
As far as I can tell, it's checked on the server side too. But I might have
another go at it tonight to be sure. The worst that could happen is that I get
a longer, more secure password ;)

~~~
JoshTriplett
The worst that can happen when you mess with form field lengths: no validation
on entry to the database, but validation later when pulling it out to check
it, so you're now locked out of your account.

~~~
SideburnsOfDoom
Interesting, I didn't know that. So the worst that could happen is that I'd be
locked out of their horribly insecure site and forced to use something better.
I don't re-use passwords, and I declined to let them store my credit card
details, so when they get hax0red, I won't lose anything worth stealing.

------
abloodywar
Even "Microsoft Accounts" have a 16 character limit on their passwords.

------
zxcdw
..and now the thread has been deleted after some further criticism...

~~~
Jayschwa
Here is a partial screen capture: <http://i.imgur.com/R5gs8HC.png>

Unfortunately, it's missing some of the newer (and frankly, ignorant and
cavalier) replies from the tech support guy.

------
MindTooth
I've added a comment, please verify.

<http://forums.stardock.com/439802/page/1/#3315287>

~~~
lucb1e
Read it, seems good to me. I added a comment as well (not in response to you).

------
jimfl
Security red flag: passwords are "secure enough."

------
rorrr
Technically, if they are using bcrypt hashes with a high enough work factor,
and salt then with something like UserID, then 12 characters is pretty damn
secure even if their whole DB gets leaked.

Of course, there's no good reason to limit passwords to any length.

~~~
peeters
Again, the point isn't about whether 12 is enough. It could have been 64 and
the point would still stand. The OP's point is that limiting password length
(to anything less than 1000 or so) is usually done to be able to set a maximum
length on the password column of a database. Password hashes, on the other
hand (including bcrypt), produce fixed-length hashes, regardless of the input
size.

~~~
adrr
bcrypt has a 50 char limit. You could always prehash(sha256) the password
before passing it to bcrypt.

~~~
jcase
It's 72 actually. I thought it was 56 as mentioned on the original [?] BCrypt
website[1]. A thread[2] on security/stackexchange discusses a workaround for
the 72 char limit. See <https://gist.github.com/4690368> for a simple test
case that shows the >72 char truncation.

The source provides a hint:

    
    
        /* Schneier specifies a maximum key length of 56 bytes.
        * This ensures that every key bit affects every cipher
        * bit.  However, the subkeys can hold up to 72 bytes.
        * Warning: For normal blowfish encryption only 56 bytes
        * of the key affect all cipherbits.
        */
    

[1] <http://bcrypt.sourceforge.net/>

[2]
[http://security.stackexchange.com/questions/21524/bcrypts-72...](http://security.stackexchange.com/questions/21524/bcrypts-72-character-
limit-and-using-it-as-a-general-digest-algorithm)

------
guard-of-terra
Passwords are bullshit. We should have a start-up about having a better way of
keeping your digital identity other than hundreds of logins/passwords, but
obviously everyone is too busy with figuring out better ways of sharing
lolcats.

Not that lolcats are bad. They are good. It's just they aren't fun anymore
once your identity is stolen. Or your mom's.

~~~
pjbrunet
"better way of keeping your digital identity"

We'll get you a seared flesh barcode, for your birthday, on your forehead.
Hands-free Facebook logins for life! Are you excited?

~~~
guard-of-terra
It's actually not very safe.

------
pjbrunet
If your password is 100,000,000 characters long, that's simply a waste of
bandwidth, CPU time, space on the disk * millions of users * 1000s of
iterations = money flushed down the toilet. And remember web servers have
timeout parameters spread across half a dozen config files. You're just asking
for trouble. Not worth it. To protect one self-important nitwit's video game
password? Even your million character password could be sniffed or worse, the
attacker might offer a hot apple pie with ice cream.

~~~
oxide
that isn't the point. the point is if there is a limit on character length,
its a clear indication that the passwords aren't being properly handled.

~~~
pjbrunet
Let's see you implement it then smartypants. So you can learn the hard way why
there is a limit. You think you're smarter than the biggest technology
companies on the planet? It's a clear indication of nothing but your own
little vendetta driving you crazy.

~~~
jblow
If you can't handle arbitrary-length strings, you pretty much don't know how
to program. Really.

------
stopcyring
Any user input needs to be filtered, sanitized, validated and limited. Please
be my guest and pass any user input to your magic hashing function, don't cry
about it later because due to some special circumstances / framework bug /
language bug / buffer overflow / extra hidden utf char, your magic function
opens a huge security hole. oh oops.

~~~
sitharus
Um what? If your hashing library hasn't been tested with a arbitrary sequences
of bytes you have bigger problems than limiting user input to 12 characters.

