I guess you're not going to tell us what the password was then. You have changed it already, right?

Oh, and for those who claim my password was a dictionary word, and thus this is a de-facto dictionary attack. Well, I just went to

https://www.merriam-webster.com/dictionary/

.. and entered my old password there:

"The word you've entered isn't in the dictionary. Click on a spelling suggestion below or try again using the search bar above."

Like I said, it *ain't a dictionary word!* It might be in cracking tables somewhere, but it isn't a dictionary word, at least not of the type you can use in Scrabble without getting challenged..

Is it worth revealing the open id provider?

Will this user come forward to claim the Stack Overflow "Hacker" badge? I don't see any wrongdoing against SO or you, since they were nice enough to point out the vulnerability and demonstrate it. You also got two good blog posts out of it. I could imagine the owner of the other site (the one the hacker helps out at, that doesn't salt their passwords) might be a little upset if (when?) word gets out that they were hacked by a trusted volunteer, but it sounds like they were warned about using salt awhile back.

This was a good read!

you should award hacker badge now... because next time next person might not rather tell you :-)

jeez Jeff arent you a bit afraid now, its official, you have a stalker.

Is using OpenID, or Windows Cardspace for another example, beyond most users tolerance or attention span? How can we get easier?

Wow, that was the anti-climax of the century. Hacking by luck is like hacking by accident. You shouldn't have to apologize for such.

I always salt AND pepper my passwords. :P

This is why I do password mixing. I have a seed word I use, lets say 'Burp'. Then I choose a word for each login that makes sense, in the case of say my yahoo account 'Mail'. Then I have a 4 digit pin of, say, '5621'.

My yahoo mail password would be 'BM5ua6ri2pl1'. And if that seems really difficult to type it is, but I use KeePass portable. It's a passord database that fits on a thumb drive and runs anywhere, so I hardly ever have to enter it myself.

I work with security software. Occasionally, I get an inside peek at how some our customers (Fortune 500, banks, governments, etc.) have dealt with security issues. Many are doing an OK job, and getting better all the time. But some... I'm telling you, it's frightening, really. They are so clueless that they cannot even begin to understand how bad their situation is.

It's the same with developers. Some are so clueless about security that they don't even realize how little they know. You tell them to "salt your passwords to prevent dictionary attacks" and all they hear is "blah blah passwords blah blah blah blah".

orange?

When people talk about dictionaries in reference to password cracking, they don't literally mean your copy of websters. Your password was vulnerable to a dictionary-based attack which is the important part. Who knows why... probably replacing some common letters with number or symbols. The important part is that any time you base your password on a word(s) in the dictionary you're vastly reducing the number of possible passwords that need to be checked.

So if Malte was right, who to blame? The guy that logged in as you made an even bigger mistake (could have been a setup).

I've started to use PasswordMaker for FF and SeaMonkey. It will store the password for you too. I use multiple Master Passwords, so it does get fun guessing at what is the password for the application. Some of them I'm able to figure out if I've entered the wrong Master Password because I make some association with a word with each password I use so I can spot the wrong ones.

Its "joshua," right? Just admit it. Its ok, many of us grew up with Wargames too.

Everyone (including Jeff) please read https://marcoslot.net/apps/openid/ and some other info on OpenID to see how it's a giant security risk.

Back in the day we spoofed the unix login with a csh script to steal passwords. Same thing works in OpenID.

Uh, Malte said: "The most likely cause was that you used it on his site and he is logging passwords or saving them un-hashed." He didn't say anything about reverse lookup on the hash.

Ha! I can do you one better. I once worked on a web application that didn't even hash the passwords. They were just plain text in the database. So I immediately suggested that we hash and salt the password to increase security, but there was a feature on the application to email the user their password if they had forgotten it. I explained that had to change, because we would no longer be able to retrieve the password, since it would be hashed. Instead, we would email them a link to where they could reset their password. They thought this would be an inconvenience to the users. So to prove how big a problem this was, I picked the first user in the database that had an @yahoo.com email address, went to mail.yahoo.com and used the same password they were using for our site. Sure enough, we were logged right in.

I just use the Password Maker plugin for Firefox, I only have to remember the one password, and no website gets my private key (salt really).

MD5 is hashing algorithm, not an encryption scheme. Two words can produce same MD5 hash, it is called MD5 collision. For more information, Google is ur friend, https://www.google.com/search?q=md5+collision

I'd just google the password. If it returns a result, I'd consider it a dictionary word.

NikNak the clown comes to mind from an earlier post. People in glass houses...

I can't help but notice that the problem was not yours, but the OpenID provider - should they have been salting their passwords prior to storing? In which case, outsourcing your authentication may be some good advice, but certainly no guarantee.

Have I misunderstood something?

Remi.

I use 1Password for Mac and iPhone. It's been a long time since I had to type other than my master password, and the password generator can create impossible to decipher monsters (if that's what you need).

Frankly, I thought that it would be more interesting than that. Come on, the guy sent a second mail to explain the hack just for the freaking l33t-51t badge! And wtf was "There's a site I help out with that doesn't salt their passwords" ... "I was able to figure out you were a user on the site some time back" !? And finally, oh!, it was some programmer's fault, but wait I am a programmer, does this mean that I'm a l33t-51t hacka!?

(I'm just a bit disappointed.)

Tim, I wouldn't classify marcoslot's attack and openId weakness but just another phishing attack. Entering your password on a non-provider site is just plain silly (it does point out a usability issue with openid but not a security risk)

This is one of the reasons I'm now advocating foaf+ssl. It's a more elegant scheme using browser certificates instead of passwords. You can combine it with OpenID to improve on security.

https://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global

One password to rule them all: https://passwordmaker.org/

I use it for everything EXCEPT important sites where I want to change the password. For my Google account for instance, roughly every year I generate a random 10 letter string (IOW (2*26)^10 possibilites) that I store in my wallet and somewhere at home. I obfuscate it slightly so that you can't use it directly should you steal it :)

The only problem with this is that some BRAIN DEAD website restrict the characters you can use for a password. But the MOST brain dead websites are those -- and they exist -- where they force stupid requirements on you while restricting the chars you can use, or the length. Ingram Micro for example is particularly annoying.

@Remi:

From what I understood, Jeff used the same password for his OpenID as he did for this (non-OpenID-using) website. The attacker stole the hashed password from the second website, unhashed it, and then tested it against his OpenID to see if Jeff was reusing passwords.

OpenID isn't the vulnerability - Jeff reusing passwords is.

In college I used to make money with that same trick. Hack a website that pays people with their paypal account, then use the password they registered with and attempt to log into their paypal account.

Some sites 1 in 3 would work, others 1 in 10.

Same things applies for many MMORP, hack a forum for a guild. And start trying passwords they used on the forum. Success rate is lower than the paypal and egold trick above, but selling their characters goods is way easier.

But...it wasn't the fact that the passwords weren't salted that let him get it.

It was the fact that he was a "trusted" individual and obviously should not have been.

Since he was helping out--I assume as a programmer--he could just as easily have temporarily trojan'ed the log-in screen and got the password that way. Or made a fake log-in screen.

You salt passwords so if someone outside of your "trusted" group gets a hold of the file, it makes their attack harder. It doesn't help against an "inside job".

This guy just shouldn't be allowed on *any* project.

While we are all waiting for the mythical promised land of OpenID everywhere, isn't it smarter to

NOT USE THE SAME PASSWORD AT EVERY SITE YOU REGISTER FOR???

:)

A pain in the ass, yes, which is why I use pwdhash. (It's a firefox extension.) It lets you have per-site passwords by entering, essentially, hash(site_domain + your_password) into password fields, rather than a straight password.

@der4444 nice that we've got criminals along for the ride here. *sigh*

Can someone link to one of these hash reversing websites?

Unfortunatley, in the real world, who doesn't reuse passwords? Surely you can't expect everyday Joe to keep track of 500 different passwords for all their sites they've signed up to.

This reminds me of the old days, first dot-com era, and for kicks we'd log into people's hotmail accounts because everyone used the same password for our service as their hotmail accounts.

Scary how easy it is for a provider of web services to potentially access your other services, especially if you don't use different passwords.

Moral of the story, use different passwords for different sites. It's unpractical for the average person, but as a techie, I don't have problems using one of the many third-party tools (KeePass)that manage login/password data. You also can't trust the webservice you're using to handle it appropriately on the backend.

It was "quidjibo" wasn't it?

Here's how I choose my passwords these days, so they don't repeat too often and yet I have a clue of what it ought to be by context.

My password has 8 characters.

The first two are two meaningful letters I took from the domain name's URL. So, slashdot.com, I use the "s" and the "d" from the two syllables.

Next I use four letters of which one is capitalized. The four letters are not dictionary words but can be hacker speak words. Like this, F11n for "fun". I could use this "fun" snippet for sites that relate to fun stuff like gaming.

Finally, the last two letters are actually two numbers to indicate the number of characters the domain name's meaningful part contains, so for "slashdot" I count 8. Pad it with a 0 and have "08".

So my password for slashdot becomes "sdF11n08".

And for OSNews it becomes "onF11n06".

And so on. It at least discourages people from easily reusing my password for other sites should they have access to them.

I do something similar to what Whaledawg does.

1) Pick a word or character combination that describes the site in question: so=Stack Overflow, gmail=Google Mail, yahoo=Yahoo.

2) Pick a constant character string to use in all passwords that can be remembered. yaba6319

3) Concatenate them. You now have a pretty difficult password to break that is also different for each site.

Google mail = gmailyaba6319
Yahoo = yahooyaba6319
Stack Overflow = soyaba6319

It isn't perfect but it is a heck of a lot better than using the same password everywhere.

OpenID is not the silver bullet for this problem. Developers are still going to have to write good password storage solutions. Why?

1. People don't want their operation-critical web applications to depend on a third party. If an OpenID provider suddenly goes down (or belly-up) or has their own security breach, there's nothing they can do. By being their own authentication provider, they avoid this.

2. When I explain to a client what OpenID is, you know what he hears? "That idiot Kathy in accounting is going to have the same login for my mission-critical application as she does for her Facebook account that got hacked last week."

So, no, I don't think I'll be getting out of the business of storing user credentials anytime soon. But that's okay, because I know how to do it correctly. And while I can't protect every user of every app from doing stupid things, I can advise my clients on what they *should* be doing. If they don't follow my advice, well, I've done what I can. Just like Jeff's OpenID provider did when they told him not to use the same password on more than one system.

Excellent read... slightly degraded I'm sure to hide the total truth, but fun nevertheless; "Horror" at its peak, huh? :)

What's better is the comments coming in about the informative tips and such -- keep 'em coming!

Cheers

By the way, I agree that this is a major let down. It's real but not very sexy. I suppose if the guy was living across the street and was using binoculars to see the yellow post it notes pasted to your computer with your password written on them you wouldn't have bothered posting about it.

At what point do you decide that this is a programming issue and not just a user being stupid and a hacker being lucky?

Wait, so you use the same exact password on the site as what you used with your openid provider? Who's fault is that? Several browsers can remember any password regardless how complex, should not be reusing.

@Matt (and others with similar rules) you will get 0wn3d

Quick test:

1. Generate the MD5sum of your password (e.g. https://www.md5generator.com/ )
2. Google it

If it finds it you're already in trouble. MD5 reversing websites are even more likely to find it; try https://md5.rednoize.com for example.

PHPBB2 stores passwords unsalted. (3 is a lot better.)

"I also run my passwords I need to be secure through a few reverse-hash websites, just to ensure that it's not stored somewhere"

Sounds a bit unsafe. If I ran a reverse-hash website, I'd probably go and add to my rainbow tables all the passwords that someone has already searched for on my same search engine.
Also, I hope s/he used HTTPS to connect to the reverse-hash website. ^^

@Anon who said: "@Matt (and others with similar rules) you will get 0wn3d"

Not as easily as Jeff did. Anyone can be "0wn3d" (what are you, a teeny bopper?). The goal is simply to make it significantly harder for the hackers yet easy enough on yourself so that it isn't a nuisance. Jeff is a celebrity. I'm not. I don't have to worry about someone tracking my usage across multiple sites. None of the passwords I "generate" exist in the online MD5 databases. And I make my variable part cryptic enough to where people aren't going to see the pattern. I'm not going to say how I do it but it is easy enough. You simply need something that you can easily remember for each site.

We needed to create a secure password hashing algorithm for a project and create multi platform/programming language implementations for easy integration.

That requirement created FSHP (Fairly Secure Hashed Passwords)

Fairly Secure Hashed Password (FSHP) is a salted, iteratively hashed password hashing implementation. Design principle is similar with PBKDF1 specification in RFC 2898 (a.k.a: PKCS #5: Password-Based Cryptography Specification Version 2.0)

FSHP allows choosing the salt length, number of iterations and the underlying cryptographic hash function among SHA-1 and SHA-2 (256, 384, 512).

You can reach Python, Ruby, Perl, PHP and Java implementations of it at GitHub (https://github.com/bdd/fshp)

It's also available in PyPI, Rubyforge and CPAN. You can easily install with:
Python: easy_install fshp
Ruby: gem install fshp
Perl: perl -MCPAN -e 'install Crypt::FSHP'
PHP: PEAR package and other platform binaries at https://github.com/bdd/fshp/downloads

@Whaledawg said "but I use KeePass portable"

Cool tool...I've been using Password Minder ( <a href="https://alt.pluralsight.com/tools.aspx">https://alt.pluralsight.com/tools.aspx</a>; ) for a long time, if anyone wants to try it out.

Whoa...I forgot to type a name, and it seems that the "try again" page had already escaped the URL...I didn't even notice on that page.

URL again: https://alt.pluralsight.com/tools.aspx

But this is kind of circular.

I would love to use and contribute to StackOverflow.com, but I hate OpenID. If my OpenID password gets owned, then I'm owned on several sites. If StackOverflow.com had it's own password scheme, and it got lost, then I'd lose only my StackOverflow.com identity. Nothing else would be at risk, since I use different passwords for different sites.

Silly, John. Everyone knows that a big, dumb, balding North American ape, with no chin, is spelled "Kwyjibo."

https://www.snpp.com/episodes/7G02.html

You're taking the wrong lessons from this. It's not "they're storing their passwords wrong" and "you should use a passphrase not a password" although I'm sure they're both true.

The correct lesson is "you can't trust more than one website with the same password" because you don't know up front how it will be treated.

In this case they'd made some (inadequate) efforts to do the right thing, but were subverted by an employee doing something they weren't supposed to. This could happen in a lot of places even where passwords are stored "securely". For example, are their procedures in place to stop a developer inserting code to write passwords to a second secret location as well as in the main DB?

So now you have to worry not only about their information architecture, but also their code review and deployment procedures and their skill in recruiting ethical people.

Bottom line is, that while this hack was made easier by your weak password and their weak hash, in absolute terms it was made possible by your re-used passwords.

Not that I ever re-use passwords of course, don't think that for a second ;-)

@Adrian

Yeah, it is a bit of a catch-22.

Optimal safety would be using a different set of credentials at each site you go to. Having one username/password compromised would only allow the attacker access to that site.

But, most people don't want to memorize 15 different username/password combos - so they use the same username/password for all 15 anyway. As demonstrated by Jeff (and yes, I'm guilty of this too, I think most of us are). In this case, I know my user/pass and I've also given it out to 15 other websites and I'm trusting each of them to property secure that information (and many of them won't). That makes much worse than OpenID.

With OpenID, you can trust a single provider with your username/password to authenticate you. Now, you know it, and one very respectable company that you might trust more than 'JoesRandomWebsite' know your information.

Now, if you are the type of person who was following the best practice approach of completely different credentials for each website; you can still do that with OpenId. You just need to create multiple OpenIds (I'm fairly confident you can do that without any trouble).

Jeff,

you forgot to check the ONLINE MD5 dictionary, apparently.

I still claim this was a hoax, to boost visits to this site.

MD5 lookup? C'mon. This has been around for years and you fell for it.

Ownz0red ? :)

Oh, and just to be more precise :

1. Programmers are the enemy.
2. Hey .. wait a second, I'm a programmer!
3. GOTO 1
4. Profit!

And that's why programmers rarely get rich...

@NMONNET:

I use SuperGenPass (https://www.supergenpass.com/).

It works pretty much the same. I did not know PasswordMaker, thanks for the tip!

I converted all of my passwords to use the bookmarklet from https://www.supergenpass.com once I heard Jeff's password got stolen. I've been reusing the same 2 or 3 passwords for all of my sites for the last couple of years, so I was pretty vulnerable.

SuperGenPass is great because it's a bookmarklet that creates hashes your password with the domain name of the site you're on. You can fairly safely use the same password on multiple sites and it creates a unique password based on the domain. I took it a step further and use the Advanced options (https://www.supergenpass.com/customize/?advanced) to include a "Stealth Password" in the generated bookmarklet.

Yeah, you have to guard your master password, but I think this is much better than having to keep track of unique passwords for various sites. Add to that, an attacker would have to know you use the SuperGenPass algorithm to use your master password.

Stop using MD5. Stop using MD5. Stop using MD5.

There is code out there to quickly generate meaningful MD5 collisions. Get out of the stone age and use SHA-256.

Nice Approach.

Just to remind people, your most important password these days is your email's password. Don't ever use it for more than just the email and have it as weird as it gets.

Oh jesus, and after all that, this so-called hacker blames the fact that the passwords weren't salted, as opposed to the fact that they were stored as MD5 hashes.

For the love of all that is holy, bcrypt it.

Aaron G: All of the MD5 vulnerabilities are about creating checksum collisions, not reverse-engineering the original password. Therefore, if the password was salted but stored as MD5, it wouldn't be possible to reverse the hash back into the original password.

Jeff,

So, if you are not using RoboForm (or some other password manager) to create random passwords for every site the only explanation I can come up with is you are either Cheap, Lazy or Stupid. Which is it? Heck RoboForm even has a free version for up to like 10 sites. Use for high value logins like your bank/openid provider/etc.

RoboForm (1Password for Macs) is drop dead simple. You only have to remember 1 password and that password is only used locally.

BOb

What will you do with the guy? I say let's give him the SO badge, he seems nice

Actually I'd say you're wrong about most OpenID providers being vulnerable to a dictionary attack. Most password schemes require like letters a number and at least 6 characters (maybe 8) long. Being this is common, most brute force tools will actually tack a number on, or even change case Bunnies1 is probably vulnerable to most tools, but would get bye a fair number of webapps as an acceptable password.

Interesting to have this happen a few days after most of the internet backed up 37 Signals when it came out they weren't storing salts with their passwords. Has the internet forgotten already?

you forgot a key issue of the problem here: that you're using md5. use ripemd-160 with a salt. there's a ripemd-160 provider built into the base .NET libraries.

Dude, I told you in the last part, and I'll tell you again: not being a dictionary based word is hard. And do you know how dictionary attack works? https://www.merriam-webster.com/dictionary/ is a pretty poor dictionary check.

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? ( https://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:

https://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?

Syd:

The reason salt is relevant is that it protects you from simple reverse MD5 lookups. If your password is "password", and there's no salt, the MD5 hash is 5f4dcc3b5aa765d61d8327deb882cf99 - there are plenty of sites on the Internet which will tell you that 5f4dcc3b5aa765d61d8327deb882cf99 is the hash of password.

If, on the other hand, I use salt, it's harder. I can tell you that the salt is SNJC6QAf7qA and it's prepended before hashing, but none of the sites that can reverse 5f4dcc3b5aa765d61d8327deb882cf99 know that fc76e940eda4fef064882c86d294c46e is the hash of SNJC6QAf7qApassword.

To prove my point, if I tell you that my password's MD5 hash is 8efe310f9ab3efeae8d410a8e0166eb2, you can look it up at https://md5.gromweb.com/ If I tell you that I salt it with just SN, prepended, and the resulting hash is d2e71c78475b829052a5ec78dbfeeae6, you can't look it up.

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.

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 https://www.codinghorror.com/, delegating to https://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).

Ok, I think i've finally heard enough, and tried it enough to agree that openid is the right thing to do.

Knowing the salt and having the hash lets you do a dictionary attack on your own machine(s), so you don't need to use a MD5 database.

Trying to maintain unique passwords for each and every site is a real pain. Even the best methods are dependent on a master password, which comes with its own problems, not the least of which is that you can lock yourself out of everything.

The faster some kind of biometric scanner comes equipped by default on every network-capable device, the better.

I am going to go ahead and guess your password was: wumpus

Could someone please explain to be -- simply but very exactly -- how a salted password would help?

From what I know, you store the salt in plaintext(-equivalent) form to concatenate the password with in order to protect against rainbow table attacks. A dictionary attack against a single password, which this was, is not harder with a salted password.

I cannot stand people who say "Hahaha I hacked you because your password is too weak" which by the way has never happened. In my opinion it's the laziest hacking I can imagine; using rainbow tables? Even lazier. Come on, get real, come up with a new exploit or something that allowed you to find the password.

But what makes me even more bleh is the actual guy in this case: "oh you signed up with a password on a site I used to work for." HAHA, that's probably the most unethical thing I've ever heard of, calling yourself ethical is anything but... That is called phishing, plain and simple; go look it up. It's so sad though, I'm so sad that people don't even try to find new exploits and just use a client side phishing attack or some stupid thing like that.

Anyway, have fun with your hopes of being someone who matters. Clearly the only thing you've done is hoped that Jeff would hire you in security; my advice, don't bother you can find this kind of "experience" in any 2-bit "network security" firm.

> If my OpenID password gets owned, then I'm owned on several sites.

How is that any different than your email password getting owned? Then you're owned on EVERY site, courtesy of "reset my password via email" links.

> 1. Generate the MD5sum of your password (e.g. https://www.md5generator.com/ )
> 2. Google it

Yep, excellent advice.

> How is an idiot supposed to work out which are the secure providers?

See above email comment. You use email, yes? Better hope they do passwords right!

> most of the internet backed up 37 Signals when it came out they weren't storing salts with their passwords.

Ooh, that's really bad. I hadn't seen that.

https://www.jgc.org/blog/2009/05/can-you-trust-37signals-with-your.html

this is nothing. i once signed up for an online dating site my friend recommended.

it was piece of crap. design painful to the eye. horrible user interaction.

but something happened the next day that scared the shit out of me. I GOT MY PASSWORD EMAILED TO ME.

i deleted my account the next day. but i have a feeling that the password i used for social networking websites and news aggregation sites is still on their machine, waiting for someone to harvest it along with password of all the other users.

"How is that any different than your email password getting owned? Then you're owned on EVERY site, courtesy of "reset my password via email" links"

Indeed, providing the hacker knows EVERY site you visit. Do OpenID providers not allow you to rest passwords via email?

i should mention too that passwords are apparently emailed to users of that dating site on a regular basis, maybe everyday.

i tried to email the guy who developed/maintain the site. didn't hear from him.

Erm... one prolonged and interwoven set of weak moments, than.

Since we are all frank and honest on the subject of broken security here... when will these oranges be uprooted and cease being pine-apples in disguise?

This orange thing has been more than the required moment of weakness now. And in case anyone (Jeff?) still wanted to retort: "Well I don't see any spam" I'd like to repeat: this site is *for the users* not *against the spammers*.

Right now, the real users are paying the cost to provide *no protection* against the *absent* spammers.

---
I forgot to enter the correct word again. Maybe the word is not correct anymore?

@Matt (and WhaleDawg)

> I do something similar to what Whaledawg does.

> Google mail = gmailyaba6319
> Yahoo = yahooyaba6319
> Stack Overflow = soyaba6319

> It isn't perfect but it is a heck of a lot better than using the
> same password everywhere.

orly? If I admin'd gmail and saw that your password was gmailyaba6319 and that you also had a yahoo email address, I know which password I would be trying first.

@WhaleDawg

While your version may be slightly more obfuscated, applying any pattern to your passwords is weakening them. And since you admit to using KeePass and rarely entering them by hand, you could just as easily be using something random and strong.

https://xenoterracide.blogspot.com/2009/05/jeff-attwood-fails-at-password-security.html < I decided to write out what I thought of this post and what I feel are inaccuacies.

I believe that passwords became invalid with the advent of the internet. They can not be made safe nor secure.

> decided to write out what I thought of this post and what I feel are inaccuacies

I am having a hard time taking an article on "inaccuacies" seriously. Also, while we are speaking of inaccuracies, you could spell my name correctly..

I think you're being a overly melodramatic in your crusade against people rolling their own user authentication systems.

Seriously, it is not that hard. The fact that many incompetent people try to do it and fail doesn't make it hard. I'm seriously amazed that so many people in this industry fail at something so simple to do.

You make it sound like people trying to roll their own encryption algorithm. Encryption should not under any circumstances be self-developed unless a) you are an expert and b) you submit your work for peer review.

Things aren't nearly so dire for setting up a user authentication system.

1: Generate a random salt value of sufficient length, 8 or more bytes is fine
2: Concatenate salt to user supplied password
3: Hash user combined salt + password with SHA-1 or better
4: Store salt and hash in the database
5: Use SSL for transmitting authentication details

That's it. If any programmer out there can't follow these simple, easy steps to secure their user accounts, they should find some other line of work - say, a waiter or a janitor.

OpenID is great for the convenience factor, but acting like anyone that doesn't outsource their authentication system is an idiot who is doing it wrong because it's so hard to do that noone else could possibly be doing it right is silly and downright incorrect.

So, it was a simple problem, after all: if you put all your eggs in a basket, you have to be sure that the basket is well protected. Specially it the basket is provided by someone else (in the case, Jeff putted some logins with the same password.... and the password wasn`t secured in one site).

Come on Jeff, tell us if he got the award :-).

And tell us the password, too! We`re curious about it...

I actually love the RoboForm software myself. I use it all of the time and it takes all of the menial everyday tasks that I have to perform on my computer daily and shortens them extremely! What once took me fifteen minutes to complete now takes me only one second because RoboForm does the same task with just one click. In fact I wrote a Report about a lot of RoboForm?s capabilities for use that aren?t even touched on in the User?s Manual for RoboForm. You can get that Report here:

https://www.theroboformreport.com/indexb.html

There is also a FREE version of RoboForm that you can download on this web page, just to test the RoboForm software out for yourself! I highly recommend it!

Many of the current hashes were made back in a time that it wasn't practical to reverse them in to their possible origins. That's no longer the case. Even with salting - although that does make it exponentially harder.

Instead, I like to:
1. encrypt the password - this almost randomises the ASCII and makes use of the full spectrum, even values you can't logically use such as zero. The encryption of the password can be salted.
2. hash the password - this removes the option of storing an actual password.
3. repeat steps 1 and 2 using different algorithms.

If you know what you are doing then the longer it takes you to calculate and store the value the longer it will take to hack.

Oh - and I don't bother with "standard" algorithms. I like customising them a bit. I don't need to keep to any standards because the "password" is limited the specific software and doesn?t need to be interoperable.

A lot of hash and encryption systems are for encrypting and signing at one place by a sender and verifying and opening at another place by a receiver ? in this situation the software is both the sender and receiver, and is in-place. So using a standard algorithm just makes it easer for a hacker.

Personally I feel that we should make sure that anyone working on security has certifications in security rather than an every-day non-certified programmer. I'm not saying an every-day programmer can't do security, just that anyone doing security should certify that they are capable and competent.

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.

I use "dictionary based" but obscurified passwords based on the provider, so that I have a half chance of memorising them eventually, and for a while stored them in an encrypted PDF on a flash drive.

Have just discovered truecrypt so now that is a text file on an "encrypted partition", so that copy and paste works more easily. And obviously I have a 24 digit non-dictionary-based password to the partition itself!

It may not be as convenient as other password managers, but it does give me the incentive to eventually memorise them, so that when I am lost in the wilderness with only an internet cafe I can still log into my VPN and print a "HELP" message on my machine at home (and then check my google reader feeds while I wait for my rescuers...)

I somewhat disagree with the common opinion about "internet and security".
What we need are better laws, not more security.
Imagine you had to build your house in a way to make it completely secure. No more windows, doors with about 10 keyholes and codes (to be changed all the time), tank safe walls and so on.

And yes, we spend a lot of money on security. Not always in a successful way, anyhow. :-)
Sadly the internet still is in some sort of "wild west times". This needs to be changed. Yes, worldwide.

I would therefore say, it is not the programmers fault as long as they take some precaution to protect their users. It's the politicians fault not to protect the programmers from outlaws.

And I'm quite shocked that someone who obviously stole other peoples money is proud to tell about it on this very blog (and gets away with it).

> Oh - and I don't bother with "standard" algorithms. I like customising them a bit

Yeah me too. I have finally settled on a modified SHA-256 that generates only 6 unique different hashcodes like ... ever. Very handy indeed, because it makes it so much easier to grep for my password hashes, and also to log onto my systems once I forget the password.

As for customer support: they have the following list of words that exhaust the hash domain in terms of possible hashes, making it so much easier to help users recover lost passwords:

bunny
idiot
zelot
obfuscation
broken
random

Fun fact: 'orange' is a hash collision with 'broken', as well as 'pita' or 'painful'

> is some form of standard in security protocols among OpenID providers,

er.. like .. https and ssl? which.. already exists? and many OpenID providers support? Verisign also offers two-factor auth via a keyfob for their OpenID accounts.

OpenID means you get to pick how much security you need. Just like your wallet contains multiple forms of identity of varying levels, so should your online presence..

md5generator.com uses server-side processing to generate the hash, so unless you trust them completely, you should probably use a client-side MD5 generator page like https://www.xs4all.nl/~jlpoutre/BoT/Javascript/Utils/md5_hashing.html or https://www.webtoolkit.info/demo/javascript/md5/demo.html (both of these generate on the fly, and give the same results).

?OpenID means you get to pick how much security you need. Just like your wallet contains multiple forms of identity of varying levels, so should your online presence..?

I think the issue I have with the argument for OpenID in this post is that on one hand it will protect idiots from themselves, and by idiots you mean people who use the same password for all logins. But then as soon as security is mentioned all the work is put onto the user to ensure they choose the right level of security, which they can only do my carefully researching a lot of technical details about each provider, and I just don?t see the idiots of the world doing that. So we have a system that will only benefit the non-idiots who don?t really need it.

The anon email started out with "I found what one could call a security hole in Stackoverflow."

After reading the follow up post, I don't see how this statement is true in the context of Stackoverflow being a website and it (the website) having a security hole. As anyone that follows this kind of topic, we all know that people are the weakest link in any decent security plan. The above statement is misleading and I think has led to the letdown or anti-climatic feeling some have expressed.

?You use email, yes? Better hope they do passwords right!?

I?m still not sure I?m getting the point about email. The argument seems to be that because there is already a global vulnerability in the form of emails, we might as well introduce another one in the form of OpenID.

I have lots of different passwords, but an attacker can bypass this by hacking my email account and requesting password resets for all my accounts. So I get an OpenID account with just one password and now an attacker can get access to all my accounts via email _or_ via my OpenID password. It seems I?ve now go two weak links where I had one ? with the added disadvantage that now an attacker getting access via my email can reset all my passwords in a single go.

So what am I missing here?

Sorry to reply again, but I just had to find a web page with an embedded MD5 generator (and *only* that) that I could save to disk and check the code, so I could be sure that nobody would be able to snap up my password. Without further ado: https://www.java2s.com/Code/JavaScript/Security/MD5HashinginJavaScript.htm (copy and paste the HTML to a separate file, obviously).

This reminded me of my blog entry from 2005, Password Authentication Without Revealing Your Password, at: https://blog.asgeirnilsen.com/2005/11/password-authentication-without.html

If you include some Javascript in the login page, all passwords will be SHA256 hmac protected, keyed with user ID, before leaving the browser.

See a working demonstration here: https://asgeirnilsen.com/hmac-password-login.html

I have also extended this scheme to challenge-response with an expiring challenge, or keying the password one more time with for instance the client IP address.

Does supergenpass make sites much more secure to a rainbow table approach? It seems to me that now the crackers need n*m rainbow tables where n is the number of password munging tools and m is the number of domains they want to crack. As the number of password munging tools seems quite low and the crackers are only going to be looking at one website at a time to try and find passwords this doesn't increase the search space by so much - just some extra time will need to be expended to generate a table for each website.

Anonymouse is correct -- that wasn't that much of a problem of "not-salted" password.
It was a problem of trusting database with passwords to the programmer who was willing to hack it and use hacked password.

On the other hand -- the hacker-programmer didn't really use it to make harm, so I wouldn't blame him for that too much.
Besides, the hacker couldn't really use that stolen password to harm Jeff, because otherwise he would be under serious risk of being identified (from login logs) and prosecuted.
Hacking into someone machine is a felony in the US.

The only Jeff's mistake was that he kept important password the same as unimportant password.

Web site that used not very reliable helper is ok with "saltless encryption". Of course, salting passwords would be better (I salt passwords on my web site using ASP.NET Membership provider), but even without salt encryption is doing good enough job.

Hey Jeff let me write your next blog post for you.

Why isn't everyone using PasswordSafe yet?

It dpes what it sounds like. You keep a list of passwords and password protect that with a master passphrase (the "safe combination").

If it sounds risky, it's not. Hear me out.

PasswordSafe is open source, so the hundreds of eyeballs thing is going on. It uses real security to protect your data; SHA-256 and the Twofish algorithm. The underlying implementation is quite good and even offers some future proofing (in case CPUs get faster).

It runs beautifully on Windows and pretty well on UNIX-like systems. On Windows it's reasonably paranoid, the safe locks (requiring you to re-enter your combination) if you haven't used it in a few minutes (tunable) or if your screensaver kicks on (also tunable).

The best part of storing your passwords in PasswordSafe is that you don't need to bother remembering them anymore. It can, invisibly, stick your password into your paste buffer so human eyes never see it. What this means is you can start using unique, absurdly long, randomly generated passwords for each web site. And with the new AutoType feature, you can configure PasswordSafe to automatically log you into your web sites at the push of a button.

It's secure AND in my case it was MORE convenient.

"Knowing the salt and having the hash lets you do a dictionary attack on your own machine(s), so you don't need to use a MD5 database."

???? What? You're describing pure brute force, and presumably you have all the time in the world.

While Jeff makes big Hay about the fact that the password wasn't salted, the #1 -- by ***far*** -- security vulnerability was the reuse of passwords across sites.

So what if the site SHA512 triple hashed it with a standard prefix and a suffixed nonce. Would Jeff have been safe?

Of course not. We're talking about insiders at this site, and anyone could just as easily log away passwords during authentication (even targeting specific individuals). Unless you trust every individual at every site that you share passwords at (which would be pretty foolhardy), you are putting yourself at risk.

Don't share passwords across sites. It's as simple as that.

What's the phrase I am looking for?

Oh yes,

All your passwords are belong to us

Cant wait for a "keypoint" site, because a "codinghorror" is already useless

>er.. like .. https and ssl? which.. already exists? and many OpenID providers support? Verisign also offers two-factor auth via a keyfob for their OpenID accounts.

Maybe I wasn't clear enough - my worries deal with the security of the OpenID providers, not the network protocols or the authentication mechanism. I'm concerned about an OpenID provider allowing <script> tags in the user profile - no comment on that part?

If everyone gave OpenID providers their logins, they'd need to become a virtual Fort Knox - as they'd become the target of every black hat & script kiddie on the planet. The way security is handled by at least some providers is scary. What I call for is a common set of protocols & audit procedures to keep the providers as secure as possible (serious protocols that is, the site I mention has that stupid McAfee Secure tested logo on it, jeez!) . Until that happens, I'm not about to give anyone the keys to ALL my kingdoms and wait for the day when they make the front page of all the tech rags.

I won't even go into the usability of the current implementations - if you try to use your Yahoo! OpenID on another site, you're greeted by a doom-and-gloom message: "Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate." To the average user, this would be enough to close the page and forget about OpenID.

Then, there is: "When you leave this page, you will be sent to openid.blah.net - a website not owned, operated, or controlled by Yahoo!. You must sign out of openid.blah.net and Yahoo! to completely be signed out of both sites." I wonder, again, how clear this is to the average user.

I completely agree with Obasanjo's "Why This Will Never Happen" part of his post on OpenID...

Does it really matter if it's a dictionary password in reality or not? He could figure it out and that should be enough. Why Not Use Something Easy = WNTUSE as a password? Or something similar? This way you can have a different password for every site, just change the ending...

I believe that there is something else to remark upon.

Jeff made a bit of a mess-up, and someone was polite enough to tell him of an exposure instead of exploiting it. Bully for them.

Also, there's a recent bit of writing on the topic of "crowds" or "groups" of people like a similar goal. The notion is that the "group" has more experience, or knowledge, or ability, than any individual in the group; the trick is to use it. In this case, we see that dynamic in play:
(1) Person #1 has visibility, and person #2 notices a vulnerability of a password.
(2) By the choices of person #2, to write a very-polite email ("dude! dictionary lookup!"), the problem is resolved and all nearby persons engage in rather helpful discussion.

The group just got "smarter", or at least, a bit more well-informed.

Thanks, Jeff and also anonymous-good-Joe.

Malte wrote the following: "The most likely cause was that you used it on his site and he is logging passwords or saving them un-hashed.". Jeff, the problem also lies in the security of your website. You never should have allowed OpenID accounts te be used for accounts with more rights, thus a seperate account for tasks with power.

I didn't read all of the comments here but I have to say that salting is so effortless. With most frameworks, authentication is generally taken care of. The password hashing scheme and salt are always found in a good framework.

As for passwords, I use SuperGenPass. While it does not support non-alphanumeric characters, it does a good job at being random and always working. The bigger problem I find is the security questions that are used for changing the password of accounts and also maintain a secure centralized email account.

10: Programmers are the enemy.
20: Hey .. wait a second, I'm a programmer!
30: GOTO 1

Damn punk kid doesn't know about BASIC RENUMBER.......

The real problem lies in so many trivial sites demanding registration and logins.

I'm looking at you Joel Spolsky.

I'm confused by that Omar ra By rd (MMM) site. Is it for real, an advertisement for advertising services, or just a clever parody that my sleep-fogged brain cannot penetrate?

If it is not satire already, it is certainly ripe for the picking by satirist and/or educator.

I worked for a Law firm last year, and everyone in the company has the same password for their CMS system. No one knows what it is other than some people in IT support and the handfull of developers they have there, as everyone logs in automatically using their windows username. The worst thing is, is this password is hardcoded into many applications they use, and there is some real confidential info stored in there. I was thinking of exposing them, but I know it would cause them too many problems at the moment, and it's not like it can be fixed anytime soon. The password has been the same for over 10 years!... All I can say is.. I'm glad I'm not responsible for that choice!

Worlds most cryptographically cool salt:

035036503530

What is so magical about salting before running MD5? Any employee with access to the source code knows your salt and can therefore perform the same attack.

@Michael C. Neel

Micheal, I disagree, the attacks presented on that site are no different then phishing attacks you can pull on almost any login system anywhere.

I also think it is a bit out of date, because, correct me if I am wrong here, I believe OpenId logins will piggyback on previously logged in session (via cookies I am assuming).

Regis, I don't think you understand, a good password salting prevents these MD5 reverse lookups on weak passwords. You can't factor the salt out of a hash and then do a reverse look up.

MD5('password123') => hash that can be looked up

MD5('password123' + 'floobardriver3k') => not so much

The social aspect of reusing the same password seems more a culprit here that the fact that it was revealed due to a weak implementation technique.

The best strategy here would be to try a variation of a base password for various sites & strictly never to reuse any aspect of a critical site password (say online banking password) with a trivial website/forum password.

And as NMONNET rightly puts it - sometimes some brain-dead websites will force you to stick to a specific password length forcing you bypass your scheme.

> The best strategy here would be to try a variation of a base password for various sites & strictly never to reuse any aspect of a critical site password (say online banking password) with a trivial website/forum password.

So, basically you're hand salting your passwords .. :)

?I disagree, the attacks presented on that site are no different then phishing attacks you can pull on almost any login system anywhere.?

Except for the obvious point that if you are phished on any login system you?ve only lost that login (as long as you don?t use the same password on all sites.), whereas if your OpenID login is phished you?ve lost all your logins.

Plus, I would say that as OpenID is already confusing for the average user, they are less likely to notice anything unusual in the phishing attempt.

Regis, salting is not magic (just like adding salt to your food) and if you do it wrong, you will not gain any extra security.

If you add a different salt to each password (which you should) before hashing it then users with the same password will have different hashes. This means that an attacker would need to build a whole rainbow table for each different stored salt which makes rainbow tables no quicker than normal brute-force. Even before rainbow tables were invented, it was still possible to attack multiple stored hashes at once with each computed hash during the brute-force run unless they each had a different salt applied to them. With different salt applied to each password, only one password at a time could be brute-forced.

Many developers understand that they should use salt but they hard-code it into their application and apply the same salt to every password. This will mean that an attacker would have to create a new rainbow table for the list of hashes but the same table would work for all of them, not just one. Some developers do even worse and add the salt after the hashing has been done which is trivial to remove and means that any old rainbow table will work, not just one specifically designed for these hashes.

Of course, some do even worse and simply store plain-text passwords in their database. This is far more common than it should be. For instance, I recently clicked the "Forgot password" button on https://www.searchsecurity.com and they emailed it to me. Sure, they randomly generated a 25 character password with upper and lower case letters and numbers for me when I signed up but then they stored it in plain text in their database and emailed it to me whenever anybody asks.

...and these guys want to give me advice on security!

Jeff, I love the phrase "hand salting your passwords". It makes security sound more and more like cooking. :-)