Bad advice on password strategy

[MrMark]

I thought this was very bad advice on computerweekly's site.

Security Zone: Conquering password paranoia - 7/29/2011 - Computer Weekly

Think of a blue sky password. A password such that in a perfect world you could remember and use without fear of compromise. Of course, in a perfect world you wouldn't need a password, but stay with me here. Let's say it is your daughter's name "Emily". Now Google the term "SHA1 hash generator" and select the top link. At the time of this article, it is the gtools.org generator. In the data field type "Emily" and submit. You will get a message digest of 40 characters. Highlight the first eight characters with your cursor; in this case "b6421c86". This is your password - a hexadecimal output resistant to dictionary attacks and impossible to reverse engineer back to "Emily". Keep in mind that the SHA1 protocol is case sensitive, so the input "Emily" will give you a different result than "emily".

Surely if users started following this advice, all the hackers would need to do is create a list of common passwords (including the most popular "password") and create their SHA1 key list from that, with which to gain access to various sites. Or have I missed something?

[Sockpuppet]

Exactly right which is why you should use a salt.

So you might use "emily" and a salt of "wibble" which would be less likely to be guessed. Its also a good idea for admins to store passwords in the database with salts. Sometime unique to each user that is generated from other factors such as the login name which means that the computation time even if someone was to get the database would make the information next to useless.

[DaveB]

I thought this was very bad advice on computerweekly's site.

Security Zone: Conquering password paranoia - 7/29/2011 - Computer Weekly



Surely if users started following this advice, all the hackers would need to do is create a list of common passwords (including the most popular "password") and create their SHA1 key list from that, with which to gain access to various sites. Or have I missed something?

Nope, it's what's known in the trade as a Rainbow Table.

It's not quite as bad as it seems though. The actual password is made up of the first 8 chars of the hash string of the meta password so the would be hacker would need to know that and select only those chars to try as the password. They would in effect need to know the meta password "Emily" and the number of charecters to select from the hash to be able to deduce the actual password from the hash string.

It works but it's still a faff to go to the site every time and remind yourself what the password was.

It's easier and arguably more secure, to use a password+salt as Sockpuppet said.

So your password would be Emily and your salt could be related to the site or system you use it on. EmilyCUK for this site, EmilyFacebook for Facebook etc.

Still not as secure as a properly chosen password for each site but quicker and easier to use than the hash sample method.

[Sysman]

Surely if users started following this advice, all the hackers would need to do is create a list of common passwords (including the most popular "password") and create their SHA1 key list from that, with which to gain access to various sites. Or have I missed something?

They already do that in cases where they've managed to lift a copy of the username/password database.

[Bunk]

The password + salt method is more for how you actually store passwords than how you choose one. The idea being that you add the salt to the password, hash it and store the hash and salt in the DB. When a user logs in, the password they type gets salted and hashed and compared to the stored hash. The actual password should never be stored as plain text.

Not really what the OP was talking about though, I know.

[Sysman]

Not really what the OP was talking about though, I know.

The idea the article suggests is that you pick an easy to remember word such as "Emiiy", encrypt it yourself, then use the encrypted result as your password.

That password itself will be encrypted again when put into a database.

The real problem I have is with this bit:

In the data field type "Emily" and submit. You will get a message digest of 40 characters. Highlight the first eight characters with your cursor; in this case "b6421c86". This is your password - a hexadecimal output resistant to dictionary attacks and impossible to reverse engineer back to "Emily".

That's eight characters. Since it's a hexadecimal representation all characters are in the range 0-9, a-f. Since eight hexadecimal characters represents 4 bytes, constructing a rainbow table is easy; it's not even using the full alphabet, mixed case characters or punctuation.

The other flaw in the above quote is that the hacker needs to guess "Emily". The hacker isn't interested in "Emily", but the hash of it.

Moreover, with non-reversible hashing schemes, more than one password can have the same hash. The hacker doesn't need to know the exact password, another password which results in the same hash value will suit the hacker's purpose equally well.

[MrMark]

The idea the article suggests is that you pick an easy to remember word such as "Emiiy", encrypt it yourself, then use the encrypted result as your password.

That password itself will be encrypted again when put into a database.

The real problem I have is with this bit:



That's eight characters. Since it's a hexadecimal representation all characters are in the range 0-9, a-f. Since eight hexadecimal characters represents 4 bytes, constructing a rainbow table is easy; it's not even using the full alphabet, mixed case characters or punctuation.

The other flaw in the above quote is that the hacker needs to guess "Emily". The hacker isn't interested in "Emily", but the hash of it.

Moreover, with non-reversible hashing schemes, more than one password can have the same hash. The hacker doesn't need to know the exact password, another password which results in the same hash value will suit the hacker's purpose equally well.

The reason I was querying the password advice in the article, was because it advised using a plain password ie emily and then creating a SHA1 hash (or the first 8 characters) from the hash.
Let's say there were only 3 common passwords (obviously there are probably a couple of thousand).
password
qwerty
emily

All the hacker needs to do is find the SHA1 first 8 characters for each password, and then use those to log in. Obviously knowing the ID is also needed, but in many cases is obvious from context. A couple of thousand common passwords is barely more difficult to produce.
As Sockpuppet pointed out, the article would be on safer grounds if it advised the user to add an additional value to the common password before producing the SHA1 hash.
Of course the password validation/storage process should also use a salt. The essential thing is to make the salt unique for each record, and one that cannot be guessed easily from the resulting stored value ie it's in the code validation but not easily guessed from the data

[d000hg]

hashing an easily guessable password is way stronger than the plain-text version. For a start, most people don't do this so it is not the first thing a cracker will try... secondly what if you drop the first 3 chars and use the next 8 as your password - you quickly have so many possibilities that a cracker has a problem since there are many different hash functions and you could do lots of things.

For casual users, I actually think this is good advice.

[MrMark]

hashing an easily guessable password is way stronger than the plain-text version. For a start, most people don't do this so it is not the first thing a cracker will try... secondly what if you drop the first 3 chars and use the next 8 as your password - you quickly have so many possibilities that a cracker has a problem since there are many different hash functions and you could do lots of things.

For casual users, I actually think this is good advice.

Yes - if they follow your tips of dropping the first 3 chars, or use a salt as proposed above...
But the article as written, could mean the majority of users just doing the standard SHA1 hash and taking the first 8 chars on their easily remembered password. Which would be too easy for hackers to solve.

[d000hg]

but it won't be the vast majority - that's one recommendation and other places have their own. And apart from anything else now a hacker has to try all the obvious passwords, plus MD5/SHA/etc variants. If they have hacked a DB then it won't matter but if they're trying to login to your account, it could still make a realistic difference.