Comments

Seth Godin • November 11, 2011 6:41 AM

Bruce, a naive question:

Why don’t websites lock an account after, I don’t know, 40 bad guesses? Wouldn’t that eliminate this problem? If one can’t use a computer to brute force a solution, then all of this to the power of infinity stuff doesn’t really matter…

Artis • November 11, 2011 6:48 AM

I find it slightly pathetic that we’re still actually discussing pass-words. It should be pass-phrases, end of story.

Ross Patterson • November 11, 2011 6:55 AM

@Seth Godin: Applications that have something of value to protect do exactly that, and the limit is usually closer to 3 than 40.

Andrew Kember • November 11, 2011 6:56 AM

Oh no! Now I’ve got to change the password to all my sites!

I wonder how you would quantify the increase in security I get by not telling people the scheme (if any) that I use to generate passwords? Assuming somebody is trying to guess my password, then I assume knowing I read XKCD is valuable information. Guessing four random words is hard, but fruitless if I actually use 12 random characters.

Natanael L • November 11, 2011 7:06 AM

@Artis: Passpoems!

How to create a strong password:

1: Make sure they are generated as randomly as possible. Words you make up in your head is often too easy to guess. Picking words at random from a dictionary is good enough in many cases. Random letters are usually good too. Feel free to use password generators, the one built into KeePassX is what I mostly use.

2: LENGTH!!! NEVER go below 10 characters for anything important. +15 is what I would recommend for almost anything today. If you use words, go for more then 5 words. The smaller the set of words you choose from, the longer it has to be. The lenght of the words is irrelevant if the phrase is longer than ~15 characters. If you pick words from a large dictionary, it’s safe with 4-5 words. Also, feel free to mix languages, that makes it even more secure.

3: If you use words, use some intentional misspellings. But don’t use misspellings in your passphrases that you make often in regular text! Try to make up a new one, or it’s too easy to guess.

4: It shall NEVER be easy to guess! If it’s a phrase, it should NOT be guessable. Any existing poem or saying or similiar shall NOT be used. Make something up! Do NOT use something connected to your work or hobbies. Even if you think it’s unguessable, it probably can be guessed anyway. Phrases should not make sense. “The sun is yellow and big and warm” is bad, “this green wallpaper particle hole calculator” is good.

5: Don’t take phrases and make them shorter by dropping everything but the first character. Removing data decreases complexity, decreased complexity means easier to guess (lower entropy). Keep them long!

6: If you can’t keep track of all your passwords in your head, try KeePassX. I use it together with KeePassDroid on my phone and Dropbox, so I got my passwords everywhere. It’s a password database that’s encrypted with one password. Keep THAT password REALLY SAFE!

7: DO NOT USE EXISTING PHRASES AS PASSWORDS!!! Do not use my password examples, do not use other people’s password examples, do not use ANY password examples. Use YOUR OWN passwords!

8: When you see “password”, think “passphrase”. Which means LENGHT!

(There might be some repetition above, but that’s A Good Thing.)

@s_horsfield • November 11, 2011 7:15 AM

The whole password versus phrase versus complexity debate misses the point: it’s about entropy. If there is information that leads to the password available then it’s a question of discovering that. Yes, brute force is an issue, but limited unless you can mount an offline attack.

My advice is simple. Generate passwords randomly without a generator. Don’t reuse passwords. Don’t rely on remembering a lot of passwords. Make master passwords that are random and strong. Remember those and change them occasionally.

2 factor is good but it makes for terrible user experiences. Don’t rely on the tech.

Sorry it’s a bit rambling…

Stephane • November 11, 2011 7:22 AM

Stop Trying To Remember password!

Seriously: pick one password and use a password management software (I use keepass, pick whatever works for you). Let it generate completely random long password.

You’ll be safer, sleep better at night, changing a password won’t be a problem anymore and your breath will be fresher.

Cuthbert the MD5 Mutant Gorehead • November 11, 2011 7:28 AM

@ Z. Constantine

“Hashing algorithms make the best passwords”

I concur, but keep it under your hat mate. We don’t want the whole world to know.

Clive Robinson • November 11, 2011 7:55 AM

@ Seth Godin,

“Why don’t websites lock an account after, I don’t know, 40 bad guesses?”

Contrary to the supposed technical reasons (DoS etc) the real reason is “Support Costs”.

Judging from some info that has been released one way or another it looks like a website such as a news site can expect about 1/3 of their users to need their password reset every year…

This accounts for why the process is often fully automated to a user nominated EMail address…

Which gives rise to another DoS attack -reset the users password- it’s not that difficult to get the automated system to send a new (or the old) password to the users nominated EMail account which in around 10% of cases the user either has alowed to lapse or has lost the password to as well…

Cr4p happens and as “good customer service” dictates the customer is “always right” so in many cases if there is an (ab)user support number the password just gets changed there and then upon request…

Oh and this (ab)user support lunacy is known to occur with some Ecomerce sites, thus you can get access to the users CC details address etc etc if they have been daft enough to alow them to be stored for their conveniance…

Michael • November 11, 2011 7:57 AM

Some of the comments remind me of the piece How To Write Unmaintainable Code, which gives some advice including for function and variable naming:

  • Creative Miss-spelling
  • Thesaurus Surrogatisation
  • Use Plural Forms From Other Languages (For pseudo-Esperanto pluraloj, add oj.)
  • Åccented Letters
  • Names From Other Languages

There is other advice in there as well. Both for picking secure passwords and for maintaining job security (and that’s certainly relevant to this blog!).

So using the just two of the points above, I could get a passphrase like: “ídiotoj rush ín” (original: “fools rush in”). Though something longer would probably be better. And the sad truth is that many system won’t accept unicode in passwords.

JRR • November 11, 2011 8:00 AM

Problems with locking accounts after a few guesses:
It doesn’t help against people who get hold of password files; in those cases people can locally try thousands of passwords a second.

It allows malicious locking of accounts – I can lock your account on you by simply trying to log in with your user ID and the wrong password X numbers of times. If I do this every 12 hours, it can ruin your week. There are people out there who would think this was great fun to do on a few thousand users with a script, whether to irritate the users or to clog up the company’s help desk with account reset requests.

Clive Robinson • November 11, 2011 8:04 AM

@ Stephane,

“… and your breath will be fresher.”

I know I’m going to hate myself for asking, but the sample size you checked this with, was it sufficiently large to avoid experimental error?

Fred P • November 11, 2011 8:15 AM

I have a password that uses an approach like Google’s – the difference is that the poetry I use is written for the password (by me), so a standard dictionary attack would presumably fail.

Clive Robinson • November 11, 2011 8:18 AM

@ Z. Constantine,

“Hashing algorithms make the best passwords”

No they do not.

I’ll assume you were not being sarcastic (as were some of the replies).

Using hashes is effectivly the same as subscribing to the “magic pixie dust” philosophy of pseudo random generation.

The strength of a password is dependant on the real not pseudo randomness called entropy going into the process, not the apparent faux / pseudo entropy comming out of the process.

If I MD5 “y” the output might look impressive but the entropy is very very small (if you know that the two likley inputs are y/Y or n/N as was the case with some encrypted comms systems and a text bassed menu system a few years ago).

Generating real entropy is a hard process because by definition it is “non determanistic” in nature. The easiest way for most humans is with a half dozen dice and a six by six translation matrix with correct distribution.

Clive Robinson • November 11, 2011 8:43 AM

I still think Bruce gave some of the best advice for the majority of users,

1, Generate (a real) random password
2, Write it on a piece of paper
3, Keep the now valuable piece of paper with the other valuable pieces of paper you own in your wallet.

Whilst this advice has aged somewhat badly due to the excessive proliferation of passwords by Internet sites, requiring uses to remember multiple passwords it is basicaly still sound for those low value sites (such as news organisations) you might only log into once in a blue moon.

More importantly carrying it around in the written down form gives you plausable deniability.
If you get accused by the authorities of some crime (which includes non aderance to Service TOC’s in the US these days) you can say quite honestly that you don’t know if somebody copied the password or not, as you often (as many do) leave your wallet on your desk when the “sandwich lady” comes around, thus yes others may have copied it etc etc.

What ticks me off is we knew back in the early 1960’s passwords were a bad idea yet hear we are over half a century later and they are still going strong. Proof if you will that no matter how bad an idea, it will stick forever if you implement it just once as a temporary measure…

The simple fact is all “memorable” passwords are domed due to the simple fact that that seven pound lump of barely warm fat between your ears is very very bad at remembering things acuratly.

So it needs “simple”, “uncomplex” ways of generating faux randomness. As we see year on year computers can search hugh spaces quickly and easily. All the system needs to know is how you go from memorable plaintext to pseudo / faux randomness. Well due to password sniffers and other nefarious software there are now huge lists of passwords in plain text that can be analysed to reveal the most popular methods.

Passwords are a long long way past their “best before date” and were pefore they were even implemented on computer systems. Why can we not bury them and move on…

Micah • November 11, 2011 9:07 AM

From the linked article:

“Given a sentence to give password advice on a billboard, I’d instead say:
A really strong password is one that nobody else has ever used.”

When do we approach the time when passwords are no longer viable for users? Users can’t be expected to achieve increasingly complex password design; passwords have “jumped the shark.”

JimFive • November 11, 2011 9:12 AM

The linked article implies that because more than one person had the same password that the password is de facto insecure. I don’t think that is a valid measure of the security of a password. Either the password is in a precomputed table and is cracked instantly(for large values of instant) or it isn’t and requires a brute force attack on the character set.
so:
bad: 2bon2b

avg: 2bon2btitq

good: 2bon2b?titq!

better: to be or not to be that is the question

best: To be or not to be? That is the question!

BONUS: Correct puntuation in the passphrase is a security feature.

JimFive

Morten • November 11, 2011 9:20 AM

Use a foreign language (without special characters)? I am from Denmark…how about:

  • Kanonslag (fire cracker)
  • Trutmund (literally “trumpet mouth”)
  • Dikkedarer (funny business, kind of)

JimFive • November 11, 2011 9:23 AM

@Clive:
“What ticks me off is we knew back in the early 1960’s passwords were a bad idea ”

What other solution is there that allows arbitrary people to individually access a system from assorted remote locations?

I think that one of the biggest problems currently is the proliferation of sites that require passwords that shouldn’t need them. Since most of a user’s online activity doesn’t really need security they don’t (and shouldn’t) waste any mental effort on a hard password. However, then when they get to something that should require a hard password they: a) are conditioned to use an easy one and b) don’t know how to create and remember a hard password.

It is also likely for a site that didn’t originally need a difficult password to suddenly need one due to the nature of the activity. e.g. Someone might register on a manufacturers site for the support forums but then later order something from them by CC. They need to change the password at that point, but do they?

Pedro Fortuny • November 11, 2011 9:56 AM

@Seth Goldin: no, that is the typical wrong assumption. After blocking the normal login to a page, the server sends a message to the user’s mail account with a OT item. It is a bit of a hassle, but not a DOS. And just DOS-ing in a user by user way is plain stupid… (do you have a list of all the logins?), then you probably do not need to DOS them.

The argument is moot as I see it: it is due to plain laziness.

This will sound like self-publicity, but here is pet-project of mine concerning “safe” storage for user-friendly passwords (assuming just the above: page lock after a finite number of attempts): put the load on the server, not on the user, who is going to do always the ‘wrong’ thing. Just make it not be ‘wrong’ by preventing dictionary attacks.

anon • November 11, 2011 10:09 AM

How about using passwords that may be over the heads of the GUI indoctrinated masses of today.

del .
format C:

And for you COBOL types:
computerpleasedeletemyfilesandformatmydrive

Henning Makholm • November 11, 2011 10:10 AM

@Morten: Those are dismal. Expect somebody who tries to crack a set of stolen password hashes to try spellchecker dictionaries for any language he can lay his hands on, as the FIRST thing.

Now, rigtigHestebatterih?fteklamme might work better.

slw • November 11, 2011 10:13 AM

@John Masterson

I love how the most secure password out of that list is: “go shove a twinkie up your ass!”

Glaurung-Quena • November 11, 2011 10:17 AM

The elephant in the room is the deplorable idiocy with which services set their password requirements.

For example, looking just at the banking sites that I use, on my credit union I may use symbols and spaces and long passwords, but I have to change the damn thing every 90 days. On paypal I can use symbols and long passwords but not spaces. On Chase, I can have long passwords, but can only use letters and numbers, no spaces or symbols allowed. And at the Bank of Montreal, I am limited to exactly 6 alphanumeric characters, (no more or less).

Some sites use my account number as the user id (generally the most secure option, except for the credit union where the account numbers are quite short), others my email, and still others a username I can choose.

Suppose I chose to use a random password generator and password locker program; I’d have to either limit the generator to insecure passwords (ie, short alphanumeric), or else manually edit each generated password to fit the peculiar requirements of each site.

It’s a complete and stupid mess, it’s ENTIRELY the fault of the banks, and the only wonder is that we are all not robbed by internet criminals far more often than we already are.

Kent • November 11, 2011 10:24 AM

Until someone accurately describes one or more real-world algorithms for password cracking, no reader can really understand what a strong password is.

Adam • November 11, 2011 10:43 AM

What I wonder is how many people have typed their password into a strength calculator, or even a rainbow table lookup site.

Jason • November 11, 2011 10:43 AM

We are, of course, also ignoring the fact that many sites ask for user registration and login passwords unnecessarily. For instance, to download a white paper or perform some other single-use action.

Adding this pseudo-security layer when this is not needed adds complexity to the UI and to the back-end, degrades the user experience (UX) and significantly increases the likelihood of a security mistake.

And yet, this remains extremely common.

To add to our woes, it often is poorly implemented too, allowing hackers to recover convenient lists of email addresses and associated passwords, that they can then use in automated attacks against widely used websites (facebook, twitter, linked-in, google, etc).

Knowing when not to use security sometimes is as important as knowing when to do so.

NobodySpecial • November 11, 2011 11:25 AM

@kent – the real world algorithm for password cracking is grab the encrypted password and try all the possibilities.

It used to be rainbow tables – which is why ‘tbon2btistq’ or ‘a passwd that nobody else uses’ used to be good advice. They wouldn’t be in the rainbow tables and so wouldn’t be cracked.

Now GPU passwd hashers are faster than rainbow tables – so ‘$d5#2F+~” is no more secure than “password” but “a very long quote even comprising simple words” is N times harder.

Assuming of course that your opponent is using GPUs, and the website doesn’t store the unhashed passwds in a file called passwd on their web server!

Austin Powers of Ten • November 11, 2011 12:12 PM

Clive:”What ticks me off is we knew back in the early 1960’s passwords were a bad idea ”

Back then, RSA tokens were the size of a brick, and nobody was going to carry one on their key-chain.

Alan Kaminsky • November 11, 2011 12:24 PM

Passwords and passphrases are too easily guessed. Biometrics are too easily fooled. Tokens are too easily lost or stolen.

What we should do is implant everyone with an RFID chip containing a unique ID, and install an RFID reader in every computer. When you walk up to any machine, presto, it knows who you are and gives you access to all your accounts.

This solution was actually prophesied in the Bible: “He [the beast] also forced everyone, small and great, rich and poor, free and slave, to receive a mark on his right hand or on his forehead, so that no one could buy or sell unless he had the mark, which is the name of the beast or the number of his name. This calls for wisdom. If anyone has insight, let him calculate the number of the beast, for it is man’s number. His number is 666.” (Revelation 13:16-18)

BTW, when it speaks of calculating the number of the name of the beast, it sounds like applying a hash function to the name of the beast, yielding a hash of 666. Now all we need is to find the preimage, and we’ll know the name of the beast.

Mario • November 11, 2011 12:30 PM

Can someone explain to me how a GPU’s 30+ billion tries a second translates into the real world, because I don’t understand. If your cracking computer is trying to break into my Facebook account, network latency will make it so that 1 try per second would be an upper limit.

When in a real world scenario would you actually see the GPU working at full force?

ted • November 11, 2011 12:40 PM

Is there a passwords shaming page for companies that only allow insecure passwords?

Virgin mobile says your password must be 4 digits and no other characters. My bank does not permit special characters.

Ian • November 11, 2011 12:49 PM

The problem with this is:

Nobody but nobody lets you have 32-letter passwords for websites.

The longest I’ve found (especially for financial sites) is 12. This is sad.

Because some DBA somewhere said that they need to have narrow fields for passwords. Or; someone has done “the least” to conform to some security specification.

And don’t get me started on “capital letter and number” requirements.

Fred P • November 11, 2011 12:54 PM

@Mario-

Anyone at Facebook (without admin privileges, but with local access) trying to hack into your account.

Anyone with the hashed version of your password (say from stealing the appropriate database) trying to break into your account.

MikeA • November 11, 2011 1:19 PM

@alan

The article at
http://en.wikipedia.or/wiki/Number_of_the_Beast

discusses the speculation. The most common I have heard is
Nero Caesar.

As for the insane “password timeout” policy, I took that up with the “director of Security” at a major manufacturer of network gear, and was told, essentially: “We know it’s stupid, but not my call”. Which implies that the CEO trusted the advice of some salesman or his pre-teen nephew over that of the designated security czar. Not wonder security sucked…

boog • November 11, 2011 1:47 PM

@ted

Whenever I encounter such needless password restrictions, I figure it’s because of the technical limitations brought about by storing passwords in plaintext; such restrictions aren’t necessary if passwords are hashed.

Sleep well tonight.

(Oh, and regarding your question: if there isn’t such a page, there should be!)

Dr. I. Needtob Athe • November 11, 2011 1:48 PM

If you use Password Safe you still need one master password to protect all of the randomly generated passwords stored inside. Ideally, the master password should be very long, randomly generated, totally meaningless, and unmemorable, which generally means that it has to be printed or written on a piece of paper.

One good method of securing the password on that piece of paper is to conceal it within a Password Grid.

A Password Grid consists of a square-shaped grid of smaller squares, sort of like a chessboard, with each square containing a randomly selected keyboard character. The user selects and memorizes an arbitrarily ordered pattern of squares within the grid, and reads each character of the password by following that pattern through the grid.

As you might have already realized, there are numerous benefits and advantage to this system.

James • November 11, 2011 2:03 PM

I’ve used lopt crack on my active directory structure to see how long it took to crack a password. It could crack a random password in no time. The ones it struggled with the most were long dictionary words with letters replaced by characters and numbers. I’ve used that type for years and haven’t had a problem with a hacked account yet.

Caleb Jones • November 11, 2011 2:34 PM

I still feel that “passwords” based off of pass phrases are the best way to go, but only if the pass phrase itself is not easily guessable.

My process:
1) Pick a sentence that is personal to me that I can easily remember but that even those close to me would not guess.
2) Pick first letters to form the “password”.
3) Pick your typical “easy to remember” cipher characters (@ ( ) | $ ! ^ 1 3 capitalization etc.)

This way when I enter the password all I have to remember is the pass phrase plus the cipher rule I applied to it (one or two times entering it is usually enough for me to memorize it).

Anton • November 11, 2011 3:25 PM

Whatever happened to external tokens?

All we need are some standards of how to implement. You can generate your own certificates. They don’t necessarily have to be CA signed.

I use password safe and a password with 30+ upper case & lower case characters plus punctuation marks. (hard to remember!), yet feel this is not enough! Plus I’m done if I catch a key-logger.

An external token allows entering of the master password on an external gadget and private keys are stored on a chip.

Banks use this methodology so I dare say there is some wisdom behind this method.

Godel • November 11, 2011 5:25 PM

Clive wrote:

“I still think Bruce gave some of the best advice for the majority of users,

1, Generate (a real) random password
2, Write it on a piece of paper
3, Keep the now valuable piece of paper with the other valuable pieces of paper you own in your wallet.”

I use that random password as the master password in PasswordMaker (Firefox add-on or small portable Windows program). PasswordMaker then generates random looking passwords by hashing the master password with the web site’s URL. I then store those passwords in Keepass.

The advantage of this scheme over just allowing Keepass to make a random password is that I can recreate my passwords at any time, even if I’m away from my Keepass database. The standalone Windows desktop version of PasswordMaker doesn’t require installation.

Jonathan Wilson • November 12, 2011 4:45 AM

Long passwords are good. But what do you do when the site has a maximum password length?

My bank for example limits it to 10 characters for some strange reason. I like my bank too much (and hate all the alternatives too much) for this one little thing to make me switch though (especially given that other banks may not be that much better)

Jonathan Wilson • November 12, 2011 4:52 AM

Can someone point me to some stuff talking about the security benefit (or downside) of mandatory periodic password changing?

Clive Robinson • November 12, 2011 7:37 AM

@ boog,

“Whenever I encounter such needless password restrictions, I figure it’s because of the technica imitations brought about by storing passwords in plaintext; such restrictions aren’t necessary if passwords are hashed.”

Actually there is another (possibly still) valid explination.

Do you know what a “NOP sledge” is?

Basicaly certain C input functions (that should not be used but still are) work with a buffer the programer passes a pointer to but not the length. So the input can easily overflow the buffer size provided….

Now if the malicious user knows this and knows how to craft the sledge, they end up smashing the stack etc and as password checking is often a privileged process the malicious user can easily end up with a privileged status or even a root shell… Such a problem occured with Sun OS just over a decade ago.

That said I’m all in favour of unlimited password length using the full gamut of input chars (except the line termination char). Thus in many OS’s the defualt line length max is usually 250 or more chars.

Assuming ordinary english plain text (just lower case chars) you will get about 1.4 bits of usable entropy from each char, giving an equivalent of around 350bits of entropy which should be more than sufficient for most purposes.

As for the question of storage in this day and age it’s definatly a non issue a tera-byte of HD storage can be had for less than 100USD. Even with RAID and host costs for NAS/SAN etc the cost is still going to be considerably less than a programmers monthly take home wage.

The real cost from a security perspective is actually CPU cycles in performing the hash etc used to produce the one way token of the password and salt for comparison to that held on the storage. Depending on how it is done, a knowledgeable attacker can use this against some sites to add leverage for a DoS attack.

Thomas Sewell • November 12, 2011 10:09 AM

What’s missing above is the impact regulation has on password policies.

Government agency X, or regulatory body Y, or industry standard Z contains a definition of password complexity requirements. After that, any company it applies to gets stuck with a password policy that probably doesn’t make sense.

That’s why you see passwords being reset every 60 days, or requiring a specific length with one number and one special character.

Even when the company knows that it’d be better to just require 20-100 characters, user’s choice of something they can remember, because that doesn’t comply with the regulations…

jdl • November 12, 2011 11:30 AM

I use “apg” to generate passwords or the built-in password generator in Keepass(x) and store the passwords in Keepass(x).

The “pronounceable” passwords are great because they don’t take long to memorize so if you find you need to retrieve a password for some login often, you quickly stop needed to unlock your password manager.

But also for any valuable logins – bank passwords, administrator passwords in some cases, etc – I always use 30 characters or whatever the maximum allowed by the system is.

Emma • November 12, 2011 2:18 PM

As an alternative to the “writing passwords on a piece of paper and sticking it in your wallet” idea, is it completely dumb to put your passwords in a text file (and NOT naming it “passwords.txt”) and storing it somewhere on your computer?

Clive Robinson • November 12, 2011 3:31 PM

@ Emma,

“… to put your passwords in a text file…”

Originaly this was just how most passwords were saved on the systems the accessed, and over time it became an obvious target.

Arguably what you sugest is for some attack senarios (ie keyboard loggers) more secure because you can cut and paste rather than type.

But not for others as the file is unencrypted, and once someone has access to your computer system then they have access to the file.

Most software password safes not only encrypt the passwords but many also store the file using file access privileges above that of the user. The reason for this is the account most likley to get compromised is a user account, and the attacker would then have to escalate the privileges to get access to the file.

However a knowledgable attacker would probably know in advance which file to go for.

And that is the first real issue for an attacker with the scheme you sugest “identifing the target”, thhat is they have to identify from the many files on your system which file is the most likley.

Unfortunatly it’s not very difficult because they can look at the “file access” time/date and it will be up there in the top ten most recent “user accessed” files.

There are ways to hide such information such as a cached webserver page, but at the end of the day it falls into the area of “security by obscurity” which whilst a valid method in the tangible world of physical objects such as wallets, is not considered valid in the intangible world of information objects such as files.

That being said if the computer you plan to store the file on never has a connection to the outside world other than through your eyes and fingers (ie you have two “air gapped” computers one for secure use and one for insecure use) this has been considered a valid security measure for many years. But again due to the likes of Stuxnet that can cross “air gaps” via USB memory devices and other storage media “air gapping” is of recent times much depreciated.

At the end of the day it is a time issue for an attacker, for “crimes of oportunity” security by obsecurity (provided it is sufficiently obscure) will suffice. But against a “directed attack” it probably won’t, and against a forensic examination of high worth not a chance.

ghuy'cha' • November 13, 2011 4:15 AM

The Google Account strength widget ranks “2bon2btitq” as “Fair” and if you run a Google search on it you get about 3,000 results. The Google billboards in the London underground do present a bug but if you continue reading the text past the cartoon Google does mention “Quadrillions of variations”.

Kevin • November 13, 2011 12:47 PM

@Clive Robinson: Never seen anybody use the term “NOP sledge” before. Most common term is a NOP sled, or perhaps a NOP slide/ramp for the pedantic.

While it makes sense to restrict user-supplied passwords to a maximum length, it doesn’t make sense to set this maximum to 6 or 8 characters. Worse yet, many websites don’t limit the form field, but instead wait for you to “SUBMIT” and then complain if your password is too long, or in extreme cases, silently truncate a longer password to 8 characters.

I ran across one vendor’s website that would let you put 16 characters into the initial signup form but then silently truncated the entry to 8 characters; however, when you went to log in later and entered your original 16 character strong password, login would fail with a “password incorrect” message.

Jay • November 13, 2011 7:49 PM

@Kevin

Sled/sledge, same thing; give us Commonwealth types some credit!

I don’t believe the buffer overflow explanation, although password length limitations have always been about fixed length buffers.

Original DES-based crypt could only hash 8 characters (because it used a 64-bit block cipher).

And I’m sure there are still some programmers who store plaintext passwords in their database, perhaps as a CHAR(16) or similar.

However, Merkle-Damgard type hashes have been around for 20+ years now…

Mike Rose • November 13, 2011 8:55 PM

Use HMACs as a simple, secure way to ensure that you’re not reusing passwords.

site-password = base64(HMAC(master_passphrase, domain_name))

Thus, breaking your password for a given site is at least as hard as forging a HMAC for a given message.

Choose a strong master_passphrase (ie. more than 48 bits of entropy. You’d be surprised how easy 12-16 random characters are to remember when you’re typing them in all the time). Truncate (or roll) the HMAC to 96 bits for a 16 char pseudorandom per-site password. You can even use MD5 if you want; for HMACs, MD5 is not (yet) considered insecure. Use SWIFFTX though, it’s considered quantum-secure. 🙂

AC2 • November 14, 2011 12:53 AM

@Mike

Good stuff, as long as the provider doesn’t make small changes to the domain name and i can remeber it accuratley (was it yahoo.com or yahoo.co.in ???)

Also must have the given functions available on the device I’m using in a trustworthy and stable implementation… (e.g. a ‘bug fix’ to the base64 function)

Moxon • November 14, 2011 4:27 AM

Some people seem to be missing the point about randomness vs complexity.

Your password only has to be random enough so that it cannot be guessed by someone who has researched you or so that it does not show up in even the most extreme dictionary lists.

As far as complexity, lets do some math.

Earlier someone mentioned GPUs capable of 30 billion tries a second? I doubt that is true but lets pretend we can launch this offline attack.

An eight character password with only lower case would be 26^8 (26 to the 8th power) possible passwords.
Thats 208,827,064,576 possiblities. Cracked in 6.9 seconds.

Now, eight characters with upper and lower case is 52^ 8 = 53,459,728,531,456 = cracked in 1781.9 seconds (about 30 mins)

Eight characters upper lower and numbers 62^8 = 218,340,105,584,896 = 7278 seconds (2 hours)

Now we test our mega cracking GPU against what should be a proper minimum password.

12 characters upper lower numbers special characters 72^12 = 19,408,409,961,765,342,806,016 possiblities = cracked in 646,946,998,725 seconds (over 20 thousand years)

So, even assuming that some hacker can perform an offline attack with 30 billions tries a second it would take 20 thousand years to break a 12 character password with letters numbers and special characters. Even assuming giant leaps in computing power in the future, this would still be un brute force able in any practical way.

Al • November 14, 2011 6:04 AM

If someone has administrative privileges on a compromised machine why do they need to crack a user’s password?

yt • November 14, 2011 6:09 AM

I suppose I may not be normal, but I have little or no difficulty memorizing long (16+ character), complex (alphanumeric mixed case with special characters) passwords for accounts I use frequently. I usually make up a phrase consisting of the characters in the password to help me remember it. When I can choose my own password, I base my passwords on things like “misheard” song lyrics, with some numbers and punctuation thrown in.

For logins that don’t really need to be secure (for example “you must log in to read this article”), I use an easier password, consisting of the site’s name plus a particular group of characters. I also never give my real e-mail address to anyone except humans I trust not to get me on spam lists, so I have a unique e-mail address for each site that uses e-mail addresses as the username.

Of course, if all else fails, I also speak an obscure language or two. 😉

Clive Robinson • November 14, 2011 6:34 AM

@ Al,

“If someone has administrative privileges on a compromised machine why do they need to crack a user’s password?”

It depends on a number of things such as the users level of security training and actual practice, but a few examples to think on are,

1, A legitimate. SysAdmin may wish to know if the users are using weak passwords. This is one way without having to modify system software to get the raw user input.

2, An attacker who has got sysadmin access would like to be able to get back in if they get booted out for some reason. Knowing a half dozen or so user names and passwords makes this easily possible if the legitimate SysAdmin does not force a password reset on all users on discovering the attack.

3, An attacker who has got sysadm access one one machine can usually leverage the password info to get access to other machines on the network that they don’t currently have access to.

4, An attacker knows that often people use the same password for many systems, they can usually login as the user onto the machine browse their mail, webcache etc and find out if the user accesses online systems and try “as the user” to login from the “users machine” (some services now use the IP address as a partial security check).

5, it is not unknown for users to use a “password safe” for “online accounts” but unfortunatly use the same password for loging on to the machine where the safe software runs as they also use to get into the safe…

And yes there are a whole host of other things that become more covert or less suspicious or more difficult to do forensics on if actually done from a valid “user logon”.

bob • November 14, 2011 8:18 AM

@anon: No, it would be more like:

PROCEDURE DIVISION.
COMPUTER PLEASE DELETE_MY_FILES AND FORMAT_MY_HARD_DRIVE.

(although, it might be “SHRED_MY_CARD_DECK” instead)

Clive Robinson • November 14, 2011 8:22 AM

@ yt,

Nice to hear from you again.

“Of course, if all else fails, I also speak an obscure anguage or two. ;)”

You never did confirm if one of them was Finnish?

Chelloveck • November 14, 2011 9:17 AM

@Clive: “If I MD5 “y” the output might look impressive but the entropy is very very small (if you know that the two likley inputs are y/Y or n/N as was the case with some encrypted comms systems and a text bassed menu system a few years ago).”

Well, sure. IF you know that. Just like it won’t take you long to crack my 4096-bit cesium-generated random password if you know that it’s one of only four possibilities. IF the attacker knows what hashing algorithm I use, a hash isn’t any more secure than the unhashed version of the same password. I’m going to bet that that’s not the case. Also, I’m going to be that I’m not the specific target of the attack; that it’s far more likely the attacker wants to compromise an account, not specifically my account. Then it’s simply a case of not needing to be faster than the proverbial bear.

Tim B. • November 14, 2011 11:17 AM

While this has been a very interesting and entertaining discussion of methods for choosing passwords, most comments seem to miss the weakest link: education of the general user population.

We in the security industry might argue the finer points of password selection for years without making any actual progress on the vast majority of passwords unless we can educate the masses, who are for the most part literate at a 6th grade level, and far more interested in any number of trivial matters than the best method to choose a password. User education efforts from the security industry in general have been poor at best.

Kudos to google for making an attempt. Their advice is the same I was giving users 20 years ago, and it does help.

Erik N • November 14, 2011 11:39 AM

Not all words are in the dictionary, in particular not in scandinavian languages where words may be created by concatenation: vicestatsministersekretærelev (vice-primeministers secretary intern, if such a position exist)

LinkTheValiant • November 14, 2011 1:52 PM

IF the attacker knows what hashing algorithm I use, a hash isn’t any more secure than the unhashed version of the same password. I’m going to bet that that’s not the case.

A 4096-bit password is a very different beast from MD5(“Y”). The first is actually random, the second merely appears to be. MD5(“Y”) will show up immediately on a dictionary lookup, where the random password will not.

The hashing algorithm used is irrelevant.

yt • November 15, 2011 3:00 AM

@Clive – yes, one of them is Finnish. Incidentally, Finnish is absolutely terrible (or great, depending on your perspective) when it comes to cryptanalysis because of all the double letters and predictable suffixes. It’s hard for humans to guess, but easy for computers to crack.

Also, forgot to point out in my previous post that in practical use, your passwords don’t have to be impossible to break. It’s like they say when you and your friends are chased by a bear: you don’t have to run faster than the bear, just faster than your friends (unless the bear specifically wants to eat you).

yt • November 15, 2011 8:50 AM

@Clive: I replied earlier but the comment system apparently ate my comment. Yes, Finnish is one of them.

On a side note, Finnish is especially easy to perforn cryptanalysis on due to all the double letters and predictable suffixes. Finnish words are hard for most humans to guess, but easy for a computer to crack.

Jonadab • November 15, 2011 10:18 AM

Why don’t websites lock an account after,
I don’t know, 40 bad guesses?

Because when an ordinary user mis-remembers their password (e.g., because they’re typing the password from a different account that they have), they almost always assume computer error (or typo) and retry the same wrong password repeatedly, often very repeatedly, on the theory that maybe the problem will just go away if they try enough. Humans are not as persistent as automated attacks, but they can be much more persistent than you might expect.

It would theoretically be possible to store (hashes of) the last N unique tried passwords, with a count of how often each one had been tried even, but I don’t know of any authentication library that currently does this.

A better solution is to increase the enforced delay between retries geometrically with the number of consecutive failed attempts. The user should be able to retry as fast as they can type up to five or six times, and after that it should tell them that they need to stop and think, because they’re not getting it right. When an automated brute-force attack hits, the retry times should escalate from seconds to minutes to hours to days. (This creates a vulnerability to denial-of-service attacks, but there are ways to deal with that provided you’re aware of the issue when you design the system.)

cdmiller • November 15, 2011 3:25 PM

@Moxon

One thing to remember is how various systems store the passwords. At anything less than 15 characters Windows systems store the LM hash, which is really two 7 character encryptions, broken rather quickly by said system. As for real world speed, I recently tested some ~$10,000 GPU systems and each was capable of 3.8 billion NTLM hashes per second. So 30 billion per second is not out of the question. Years ago there were million dollar theoretical system designs proposed to brute force DES. Now we have $10,000 off the shelf systems doing 3.8 billion MD4 hashes per second or more.

Dirk Praet • November 15, 2011 6:15 PM

I use the password BruceSchneier for all my accounts. Any cracking algorithm gives up immediately in fear of retaliation.

Randall • November 20, 2011 11:33 PM

So I wonder how long until, say, the business and ecommerce fields sour on passwords as a good enough way to protect a user’s cloud accounts. And I wonder what they do about it. Will it take costly breaches of thousands of accounts using password lists? Or longer — say, a million breaches that make up a few percent of some site’s autdience? And what will be the next step for everyman’s auth after passwords — two-factor using your computer and/or phone?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.