It seems that the Perl Monks database has been compromised through some kind of security hole on the server that hosts it. That would, of course, be bad enough. But it seems that the user passwords in that database were stored in plain text. So whoever got the database, got access to the passwords of every user. Some of those passwords (those belonging to the saints and the janitors) have been shared publically. And changing your password might not help as the original vulnerability hasn’t been plugged yet so the same people could grab any password that you change it to.
More details will probably appear on Perl Monks once they’ve worked out what they are going to say. But there is some discussion starting up here.
I’m astonished that I still have to repeat this, but please take this advice:
- If you’re running a site, do not store passwords in plain text
- If you’re using a site, do not use the same password as you use on other sites
I don’t think storing plaintext passwords for websites is a big deal.
London.pm (and every other mailman site) does it. Your blog accepts plaintext passwords over http too.
If someone hacked perlmonks and they had stored MD5 hashes instead of passwords, then the attacker could still have extracted the passwords in a small amount of time. If they had been hashed more securely then passwords would still have to be changed, because the passwords could have been grabbed on login by altering the perlmonks code or with packet sniffing.
There’s no strong reason not to hash passwords mind you.
“I don’t think storing plaintext passwords for websites is a big deal.”
Then you should not be writing websites.
“There’s no strong reason not to hash passwords mind you.”
I can decode a plain text password in 0.00 seconds without the assistance of a computer.
It will take me at least an hour for me to find or write a decent md5 brute force cracker, and then probably at least an hour for an easy password. If the passwords are salted, and I don’t have the salt, I probably won’t be able to crack it.
There’s a big difference between an idiot who hacks a site and displays a list of plain text passwords, and an idiot who hacks a site, and brute forces several thousand passwords and then displays them. The difference is probably several weeks. Hashing passwords gives you that time from when the compromise occurs, to when the attacker can use that password against you on other sites.
Like I said, there’s no strong reason not to hash passwords. On the other hand, like you say hashes just buy you time (if you detect the original intrusion). I consider this about as big a deal as using a plaintext protocol for auth, and nowhere near as big a deal as for example having a good fine-grained backup strategy.
“Like I said, there’s no strong reason not to hash passwords.”
I’m an idiot, I missed the ‘not’ in that statement. I still don’t believe there is any excuse for not using some form of encryption.
Yes I agree there’s no excuse. I just think it’s strange that somehow having plaintext passwords is held up as a big deal for a site that’s just been hacked. If a hacker has full access to a website including its database, what does it matter that the passwords are plaintext? All auth is bypassed. Having looked at the passwords it seems many of the users (including Dave) don’t take perlmonks password security seriously, and that’s fair enough — it’s only a forum website with plaintext auth.
It’s embarrassing to have a list of passwords published, but it seems more serious that they got comprehensively hacked in the first place.
I am wondering whether I had a perlmonks account that has been compromised. The thing is, I don’t remember what user id I might have picked (although I would recognize the email address). It is likely that if I did set up an account, I used the same password for other sites. Does anyone have a copy of the list? If you want to strip the passwords out first, that’s fine; I’d just like to look to see if any account belonging to me is in there.
I think it’s time the code running the various high usage Perl sites be peer-reviewed; initially for security only. If at a later date the owners are willing then reviews apropos improving / re-factoring the systems could take place, but a security review by a small group of trusted, competent members of the community is a must if we are to engender trust in these systems.
As most are closed source NDAs should be offered. And as we all know, the code we wrote 10 years is worse than what we wrote yesterday (if it’s not, what have you been doing for the past 10 years???) meaning judgment should be reserved on the quality of the code.
I’d happily volunteer to be part of the group if people think I’m competent enough 😉