Linode.com Forum

[HockeyInJune]

No, it's not SQL Injection or a fancy CSRF Exploit. I have an issue with the maximum password length allowed for the Linode Manager. 16 Characters is not secure password length. I think it should be increased to a suitable 128 or higher. Also, "punctuation characters" does not clearly state what other characters may be used. For instance "*" is not a punctuation character, but it may be used in a standard 46 character set, and "," is a punctuation character, but it would not be used in a standard 46 character set. A standard 46 character set being [abcdefghijklmnopqrstuvwxyz1234567890!@#$%^&*()].

Sure one could argue that 16 characters (alphanumeric and/or punctuation characters, which we will round off to 46) would take insanely long to brute force over the Internet. However, what happens when Internet Speed increases hundredfold, when everyone gets their own dedicated fiber optic line. It could happen. In addition, what would happen if the database fell into the wrong hands, a 16 character password would be no match for any low-end super computer these days.

With a 46 character set, a 16 character password would have (46^16) possibilites:
401906756202069927458308096
4.0190675620207*10^26
Just doubling the number of characters (46^32) makes a very large increase in possibilites:
161529040680870074100680119806799048214504294859145216
1.6152904068087*10^53
Increasing to my suggestion (46^128) will garuntee a secure password for many a decade to come:
680773207367770584292618095336734061136739708276446877551382164373170433447586156597048478988324682890062382565602216985624442354929795225031328667526286513880330481553157071501702115044986806565884694921096462336
6.8077320736777*10^212

Conclusively, I believe many people, including myself, will appreciate the ability to choose a longer password.

[atourino]

Correct me if I'm wrong but 16 characters *is* 128 bits (assuming of course 8 bit characters).

[Oddish]

Um. What kind of terrible login system doesn't go on alert when there are 100 unsuccessful logins in the last second? Brute forcing a database password, especially over the internet, shouldn't be nearly as easy as you think it is.

Also, it would be 46^16 + 46^15 + 46 ^14 ... + 46^1 + 1 possibilities. It's not locked at 16 characters, it's 16 characters max.

That's 4.10838017451005e+26, or approximately 410838017451005000000000000 possibilities. But that's neither here nor there, really.

[HockeyInJune]

Oddish wrote: Um. What kind of terrible login system doesn't go on alert when there are 100 unsuccessful logins in the last second? Brute forcing a database password, especially over the internet, shouldn't be nearly as easy as you think it is.

I argued against that point.
"Sure one could argue that 16 characters ... would take insanely long to brute force over the Internet."
But even so, with the right throttling and proxy hopping, and an indefinate amount of time, any brute force deterrent is futile.

And if the database fell into the wrong hands, the database would be completely by it self, no code to "go on alert."

Application Security shouldn't be nearly as easy as you think it is.

Quote: Correct me if I'm wrong but 16 characters *is* 128 bits (assuming of course 8 bit characters).

Perhaps I was not clear, I meant 128 characters.

[Internat]

Correct me if im wrong, but i would imagine if the DATABASE fell into someone elses hands, there are bigger issues then weather they can reverse engineer your password, assuming of course that its not stored in plaintext.

Credit card numbers, DOB, addresses are all information i value a lot more then someone "attempting" to work out what my password is.

[gyver]

For most crypted database, the crypto used requires some pretty heavy computations and modern processors can't try more that thousands or tens of thousands of passwords per second.
I'll let you do the math...

This also means that even if you can access the site with huge pipes and nothing is preventing you to try passwords as fast as the web server answers you won't get far (you would only DoS the server(s)).

[HockeyInJune]

Internat wrote: Correct me if im wrong, but i would imagine if the DATABASE fell into someone elses hands, there are bigger issues then weather they can reverse engineer your password, assuming of course that its not stored in plaintext.

Credit card numbers, DOB, addresses are all information i value a lot more then someone "attempting" to work out what my password is.

Heh, this is true.

[nabber00]

If you ask me, I'd much rather be typing a 16 character password and change it every 5 years instead of typing the same 128 character password at EVERY login for the next few decades. If you change your password often enough you obtain an equivalent security level to a longer password when concerned about brute forcing.

[kbrantley]

You could have just asked for a longer maximum password length, instead of labeling it as a security hole.

You could argue that 128 characters isn't enough either, as someone placed in the same datacenter as the server could bruteforce them even faster. What's your point?

[pclissold]

Maybe it would be better to have the facility to only use certificates for authentication - so that, once your certificates are installed, you have the option to disable password logins - the same as lots of people do for their own ssh daemon. I can see this being a potential support problem (my certificate is screwed up so I need passwords turned back on) but not insoluble (first time in a year = free; second time = $10; third time = passwords only for you).

[HockeyInJune]

kbrantley wrote: You could have just asked for a longer maximum password length, instead of labeling it as a security hole.

I never said "hole." It's a Security Issue, and I believe it needs to be addressed.

kbrantley wrote: You could argue that 128 characters isn't enough either, as someone placed in the same datacenter as the server could bruteforce them even faster. What's your point?

Fine, let's go with more, the more the better. My point is that if one can argue that 128 characters is not enough, 16 is certainly not, and the maximum should therefore be increased.

[HockeyInJune]

On the issue of passwords, I had recently changed the root password of my Linode to something much larger than 16 characters. To my great dismay, the next time I attempted to log into my Linode it refused to grant me access. I couldn't find much documentation about a Linux or SSH maximum password length, but I found one person asking about a maximum length because the same thing happened to him. Now, I will probably be using keys from now on, so please don't suggest it.

So I ask: What happpened here? Is there a maximum password length I am not aware of? Please enlighten me.

Oh, and thanks to the Linode Manager, which I love :D, I was able to reset my password, quickly and easily.

[mwalling]

Passwords on your linode have no connection with passwords you use for linode.com

[OverlordQ]

You're paranoid, and not in a good way.

[Arachnid]

Let's see. 16 characters, with an alphabet of [a-zA-Z0-9!@#$%^&*()-=_+[]{};'\:"|,./<>?] (92 characters) allows for 92^16 = 2.6 * 10^31 possible 16 character passwords. Running "openssl speed sha1" on my Linode indicates it can probably do about 2 million SHA1 sums per second. 92^16 hashes / 2000000 hashes per second is ~4 * 10^17 years. Let's generously assume that the password you use to access your linode is so valuable someone is prepared to dedicate an entire datacenter's worth of machines (say, 2000) to cracking it. That reduces the time to crack your password down to a mere 2*10^14 years.

So as long as you're prepared to change your password every few millennia to be on the safe side, you should be fine.

I can see the point of asking for a longer password field - after all, passphrases can be more secure than an equivalently easy to remember password - but claiming that it's 'insecure' as it stands is wrong.