also noting your ‘md5’ note, see ‘rainbow tables’ all hashes up to 8 characters are stored, and reversed.
Jeff, I work at Merriam-Webster’s website, and I just checked the logs for recent queries that weren’t found in our dictionary… j/k
So this hack was number 3 on your account? ( http://twitter.com/codinghorror/status/1700181914 )
Jeff,
You don’t mention the shoulder surf on your list of password acquisition methods. I think it is worth mentioning this old and crude technique because
1/ There is a danger of getting bogged down with more technical methods, and not seeing the wood for the trees
2/ In this day and age it isn’t always as simple as looking out for someone standing behind you! More about this here:
http://www.softwaredebugged.com/computer-security/personal-computer-security-two-simple-precautions/
- Mark.
I have a question.
Why is it relevant that the site didn’t salt the passwords? Surly if the guy helped on the site, he would have known the salt, which makes the whole existence of said salt moot?
So, does the guy earn the Hacker badge?
Inquiring minds want to know: DID HE GET THE HACKER BADGE?
@Syd: No, when you salt the password, you prepend it with a random string which, even if a hacker knows the salt, makes the password longer. Long passwords cannot be cracked with rainbow tables, or these MD5 reverse lookup sites, because you can only lookup the hashes of passwords up to a certain length. They basically go through every possible string, get its hash, and store it for lookup. Passwords longer than say 15 chars make this impractical.
Jeff,
Until there is some form of standard in security protocols among OpenID providers, I will not trust any of them. I know of a provider who is claiming to do precisely this outsourcing to third-party websites so they don’t need to do any user account or profile management, who will accept script tags in their user profile fields…yes, you’re reading right - no need to even do eval() tricks to get it to take javascript. How can I be sure, as a normal (L)user, that my OpenID provider is safe secure? Do I have to hire someone to audit them?
Thanks for a great couple of posts!
You shouldn’t use OpenID for various reasons.
OpenID:
-You giving away a key for houses away for free to let other people lock up the doors.
-Your puplicing your identity for free and enjoy it.
-You bind your ID to a provider who can close, if so you can forget about logging in to sides which have nothing to do with the closed provider.
- It doesn’t prevent Phishing, it just enables a fisher to log in to more sites a lot easier
To be sure you can trust an openid provider (and no, i don’t trust google, look at the terms of use) you need to set up an own OpenID provider.
I would not log on with a third party provider for logging on just because the programmer of a site is to lazy or incompetent to write a own login mechanism.
And sreg is like sharing your personal data with ease to other sites which just don’t need to know them. For gods sake, even a lame unsalted md5 hash is better than openid.
Lots of posts about salting. Use the new, warmed up, salt-rehash, orange-256 MD% kaboodle.
wouldn’t use openid anyway.
All the technology in the world means nothing when the password, intended to be typed by a human, is hard to remember. Most computer-generated passwords fit into that category.
It gets written down somewhere, including in pencil on the keyboard.
The password I selected for one corporate environment is something I can remember how to type, but I don’t know what it is. I hold down a certain modifier-key (shift or control or the like) and walk across the keyboard in a pattern that I like. I remember the pattern, and that’s my password. Jesus only knows what the password is – I make it a point to not know, or care.
I just know how to type it.
There are more OpenID providers than websites accepting OpenID for login…
Why would this person get a hacker badge?
He had access to a hash of Jeff’s password. It was more of an exploit than a hack.
At least they were hashed. Sites like plentyoffish.com store them in plain text and reguarly email them to their users…
Jeff,
Thanks for your incredibly useful post. I know a bit about it but it is so easy to let your guard down and forget that we are all vulnerable…even those of us who know a bit.
The thing this post reminded me of is that I pretty much presume that most of the sites where I have a login is doing it the right way (hashing with a salt). But that is probably opposite from the truth. (One way to know…if you lose your password and the site is able to send your password then they are encrypting the password (we hope - redddit redux) not hashing with salt.) Of course for trivial sites this is not so bad (or is it?) but for all sites where security is hugely important (banks, paypal etc) you wonder if they are hashing? But even for those that are hashing…there is no way to know if they are salting?
For the record…one thing I do is I give EVERY site I join a unique random password of various strength (depending on importance) and store that data using RoboForms and one impossible to guess password which I have memorized. Of course…if that is ever compromised then a hacker would have the keys to my kingdom. (Guido could break my legs or threaten my family I suppose…but if my data ever becomes that important then I suppose I will have a bodyguard, too.)
One last thought…for my personal computer…isn’t a biometric solution LESS secure than a strong password. If Guido wants to hack my computer all he has to do is kill me and cut off my right index finger. Gruesome thought. Not perfectly related to your posted but I recently thought of that.
Thanks for the great post.
Seth Spearman
@Doug T:
Maybe it’s another one, but something tells me his OpenID address is http://www.codinghorror.com/, delegating to http://codinghorror.myopenid.com/.
Are you equipped and willing do everything necessary to protect idiots like me from myself? That’s a key part of the promise of OpenID
I’ve yet to be convinced that that is a promise OpenID can keep. Even if you can guarantee that all OpenID providers are as secure as possible, I think idiots will still find ways to make fools of themselves. For example, how do you protect an idiot from phishing attacks, or from simply handing over their password for an Easter egg.
ìWe outsourced our user credential system to people who are much better at it than us (well, depending on which OpenID provider you pick). ì
But you didnít outsource the task - you make every user responsible for their own outsourcing. How is an idiot supposed to work out which are the secure providers?
If you know or obtain the salt the password can still be comprimised using MD5 cracker. easy passwords take 5 mins.
Gabriel Ross -
@Syd: No, when you salt the password, you prepend it with a random string which, even if a hacker knows the salt, makes the password longer. Long passwords cannot be cracked with rainbow tables, or these MD5 reverse lookup sites, because you can only lookup the hashes of passwords up to a certain length. They basically go through every possible string, get its hash, and store it for lookup. Passwords longer than say 15 chars make this impractical.
Close, but want to clarify a bit. The length of the hash is not what makes salting effective. If you put ABC in front of all your passwords before hashing, you aren’t changing the length significantly, and you certainly aren’t making your site impervious to rainbow attacks. If the attacker knows your seed they can then generate a rainbow table where all solutions are ABC plus 1-8 characters.
For the examples below, imagine a user who uses abc as their password at every site.
The MAIN benefit of seeding is that it turns a good enough solution into a wrong solution. ABCabc and ABCxyz may well turn out the same hashcode (they don’t, but pretend they do); this is the nature of a one-way hash. It is, however, highly unlikely that that is true AND that abc and xyz also turn out identical hashes (assuming a hash algorithm like MD5 where prefixes do not uniformly affect the output hash).
Thus, while the rainbow table will show that ABCxyz is one valid (seeded) password for your site, and therefore xyz might have been entered by the user, and indeed, entering xyz at the login for your site will let them in, entering xyz at another site where the user used the same password would NOT work (because they hashed abc, which hashes differently from xyz).
Likewise, if abc and def turn out to have the same hash, and another site is compromised and the user is thought to be using def for his passwords, then entering def on your site will not work (because ABCdef and ABCabc do not hash to the same value, even though abc and def do).
The importance here isn’t so much the secrecy or security of your salt, but rather the uniqueness. If another site with the same salt and the same users is compromised, you are open to attack. However, even the most basic salts provide a huge level of protection larger than no salt (which due to lazy programmers is almost always going to be non-unique).