4

Why when we sign up on sites like Facebook and Gmail do our passwords have to be 8-12 characters in length, or some other cap? 8-12 spaces are finite, but you can make your passwords more "secure" by adding uppercase letters and numbers.

It looks like Gmail passwords cap out at 100 characters (as of Sept 14 2017): https://i.imgur.com/vko3h2x.png

I think that the real reason our passwords are capped in length is for matters of legality, above any shortcomings in cryptographic efficiency. If the company needs to access your account they will access your account and don't want any obstacles in doing so. At first I thought they put a cap on passwords because if they store passwords with longer lengths on their servers they will run out of space on their drives, but char values like passwords doesn't occupy much space, it is just a bunch of letters and numbers after all. Perhaps PBKDF2 with HMAC can decipher passwords of any length, but it will increase CPU processing time in doing so as well as space on a drive (perhaps around 1GB for a very long password).

Should companies with very large data centres be able to accommodate the simultaneous hashing of all the users of their platforms?

Passwords are capped at 12 (or whatever that number may be, 100 for Gmail because Google has the money to accommodate hashing to 100 characters with ease on their systems) because password key derivation function techniques are currently not at a level to decipher passwords of longer lengths efficiently. This means if you wanted to make your password 250 characters long you wouldn't be allowed to because the company doesn't feel it would be equipped to crack your password should they ever have the need to in an efficient manner.

Are we truly free? what motivation do we have to make our passwords more secure than "password" or "12345678" if there is a cap imposed on our security? It seems the message they are delivering is that you can be secure, but not so secure that it makes our job more difficult.

A lock will keep out most intruders, but the ones equipped to crack the lock will do so. Do we choose the lock that will keep the most intruders out, or buy any average lock and hope the ones that can crack it don't come by our houses?

By making our passwords more secure through the addition of uppercase letters and numbers we begin to limit the number of people who can crack the password but people will still crack the password if they want to.

wanttolearnmoreaboutladders
  • 51
  • 1
  • 4
  • 3
    You seem to have a misunderstanding of password hashes, the hash will be the same length regardless of the length of the password. I'm also not sure what question you're asking. – AndrolGenhald Sep 14 '17 at 16:46
  • @AndrolGenhald it will take more time, more space and the CPU will be more occupied trying to decipher a password the longer it is in length. – wanttolearnmoreaboutladders Sep 14 '17 at 16:50
  • @AndrolGenhald why isn't password length cap infinite? And why can't I have a password that is 575 characters in length? – wanttolearnmoreaboutladders Sep 14 '17 at 16:51
  • @AndrolGenhald Google's password length cap wasn't always 100 characters, It was lower before. As time progresses I'm sure we will see their length cap increase. – wanttolearnmoreaboutladders Sep 14 '17 at 16:57
  • 2
    I was curious so I tested `time { printf 'a%.0s' {1..10} | python -c 'from sys import stdin; import bcrypt; print(bcrypt.hashpw(stdin.read(), bcrypt.gensalt(12)))'; }`. 10 characters took 0.303s, 100,000 characters took 0.376s, 1,000,000 characters took 0.981s, but when testing it with python printing stdin directly the increase was exactly the same. Conclusion: absurdly long passwords increase i/o time, but don't affect bcrypt significantly. – AndrolGenhald Sep 14 '17 at 17:07
  • @Xander No, not really. He clearly states in his question "I understand why 100000000 might be a problem..." My question is why is 100000000 a problem if we really want TRUE security having a password of that length shouldn't be a problem. And the first answer to that question with the monkeys and bananas is exactly the reason we should be looking at this question and giving a real answer and not one that says "we don't do it because we don't do it" – wanttolearnmoreaboutladders Sep 14 '17 at 17:07
  • Since printf was the bottleneck I tried again with /dev/zero and tr: `time { head /dev/zero -c 10 | tr '\0' 'a' | python -c 'from sys import stdin; import bcrypt; print(bcrypt.hashpw(stdin.read(), bcrypt.gensalt(12)))'; }`. 10 characters took 0.308s, 1,00,000 characters took 0.306s, 100,000,000 characters took 0.446s, and 1,000,000,000 characters took 3.020s. – AndrolGenhald Sep 14 '17 at 17:16
  • Either way though, the hash is always the same length, there may be more i/o for a longer password but the space on disk will always be the same. – AndrolGenhald Sep 14 '17 at 17:19
  • 1
    **Edit: Oops, looks like I just summarized the accepted answer...** You need SOME limit, what limit is used is probably whatever the dev arbitrarily decided "should be long enough for anybody's real-world password". And a 32-character completely random password is, as discussed elsewhere on this site, completely unbreakable without consuming the entire energy output of several suns, so really 100 characters is plenty long enough for someone as...shall we say, "privacy-conscious"...as you seem to be. – Ben Sep 14 '17 at 21:12

3 Answers3

21

If you don't mind me being blunt, I think you have a lot of misunderstandings in your post, and a lot of your conclusions seemed to be based on assumptions of what amount to conspiracy theories. First, let's be clear about a couple things, which I feel should be sufficient to dispel some of your assumptions and conspiracy theories:

  1. Google does not have the computer resources to crack a 100 character password. The entire earth does not have enough computing power or energy to do such a thing. In fact, even a truly random password with only ~20 characters is long enough to be uncrackable by anyone (presuming a simple brute force attack of course, and ignoring phishing/algorithm weaknesses/etc)
  2. If google wanted access to your data they wouldn't have to try to crack your password anyway. They could just update their source code to store the plain text version of it the next time you login. The same is true for any website that you log in to. Anyone running a server doesn't have to crack your password to read it: it is waaaaay easier than that.

As a result, your general statement that companies have password length maximums because that allows them to crack your password when they want to is, without exception, completely wrong.

So why are there maximums? This question discusses that for many legacy systems:

What technical reasons are there to have low maximum password lengths?

Google is a separate matter: a 100 character maximum is not actually unreasonable. I doubt anyone is trying to use 100 character passwords, and even password managers don't (because 100 characters is absolute overkill). There may be technical reasons with their cryptographic algorithms that require a maximum of 100 characters, but more than likely it is an arbitrary limit put in place because some limit is needed, and there is no practical reason for having a password that long in the first place.

To reiterate one more point, there is a physical limit to the length of a password that can actually be brute-forced. It comes down to energy considerations, and the minimum amount of energy required to run computers that could crack passwords. The overall gist of it is that for long enough passwords, there isn't enough energy in the entire world to crack the password, even if you had infinite computing resources to throw at the problem:

https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/

https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year

Also good reading for you, to help you really understand some of the issues around password length:

https://www.infoworld.com/article/2655121/security/password-size-does-matter.html https://security.stackexchange.com/a/118457/149676 https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/

Conor Mancone
  • 30,380
  • 13
  • 92
  • 98
  • Perhaps I am not very coherent overall, but I am not wrong in my thinking that longer passwords are more secure. – wanttolearnmoreaboutladders Sep 14 '17 at 17:28
  • 4
    You are 100% right about that: longer passwords are more secure overall. However, there is a law of diminishing returns. There is also a very real physical limit to the length of a password that is actually brute-forceable, based upon energy requirements from entropy calculations. I updated my list of links with another one that discuss the actual physical limits to password cracking. There is definitely a password length after which, there really isn't any point of making the password longer. – Conor Mancone Sep 14 '17 at 17:34
  • Oh well... maybe i got the Image but you said it way much better. And also missed the conspiracy "Google trying to hack you" approach. – Azteca Sep 14 '17 at 17:46
  • +1 for better answer than mine and awesome references. – Azteca Sep 14 '17 at 18:02
  • Also +1 for "and there is no practical reason for having a password that long in the first place" – Royce Williams Sep 14 '17 at 18:38
  • The longer the allowed input, the easier to supply an input that could cause a hash collision, but I doubt it is part of the reason here. – Jacco Sep 16 '17 at 10:02
  • @Jacco, I'd be curious to see some information about that. My own expectation is that the collision chances are effectively the same regardless of message length, since the hash itself (which is where the collision happens) is fixed length. – Conor Mancone Sep 16 '17 at 19:50
  • @ConorMancone, it would be better to ask a new question for that, rather than attempting to answer in comments. – Jacco Sep 17 '17 at 17:16
  • @Jacco Here's your chance! I'm happy to learn more: https://security.stackexchange.com/q/169711/149676 – Conor Mancone Sep 18 '17 at 17:44
2

Because of the "Ease of use, functionality and security triangle" Taken from: https://cehv7guide.wordpress.com/

We're only dwelling in the ease of use vs security since the functionality doesn't imply much work increasing the size of the password (Like google the image you shared of google having a limit of 100 - which is an overkill IMHO). Since the mid 80's the internet has been for available for the common people, the idea of a password in security is "What you know?"

Yeah, a password can be 100000 characters long maybe (Note: the default max size of an input it's 524288 length), and it's still unfeasable to crack it in most of today's implementation, also who can remember a 20 password length? maybe a 100? maybe you can remember a really long sentence. No one will ever use the 1st chapter of the "Don Quixote" as a password, human memory ain't THAT great.

Sure maybe you can store it or use something like "LastPass" but that's not for a common/daily user.

TL;DR Increasing the maximum doesn't keep adding security, at certain point it starts removing "ease of use" and adds little "security".

Azteca
  • 1,116
  • 7
  • 16
-1

Short answer: lazy programmers implementing password storage poorly.

Longer answer: legacy password systems the web sites need to inter-operate with, which don't understand hashes and have to use plain text passwords, with limits.

Additionally, there is a usability question. Many end users don't use password managers, and it is a cost to the business to run support lines when users need to reset their passwords. It is in the business' financial interest to "limit" users in some ways, so they don't pick a 100 character password, and then mis-type it.

A major banking web site I won't name doesn't tell its users that it lower-cases all passwords behind the scenes (you can log in with any mixed case password, change the case, and it will still work) while others will let you log in with the phone keypad numeric equivalent of your password, because it shares a back-end system with the phone verification system.

JesseM
  • 1,902
  • 10
  • 9
  • 10
    I don't find it plausible that the Google security developement team consists of lazy programmers. – Jacco Sep 14 '17 at 17:04
  • I never said Google were lazy, I answered why (most) systems have such small limits. Google supports 100 characters, which is way *more* than needed, or NIST guidance suggests https://pages.nist.gov/800-63-3/ If you care about entropy and brute forcing that is hardly a limit. 20 (random) character passwords are functionally beyond practical brute forcing, and 100 is overkill. – JesseM Sep 14 '17 at 17:17
  • @JesseM so by that merit, what do they think of passwords 1000 characters in length? – wanttolearnmoreaboutladders Sep 14 '17 at 17:20
  • 3
    20 characters might not be enough for people who want to make good passphrases easier to memorize, eg diceware style passphrases. – AndrolGenhald Sep 14 '17 at 17:20