back to article PerlMonks suffers unholy hack

Web developer site PerlMonks is obliging users to change up their passwords, following a successful hacking attack. The community website, which provides a forum for users interested in Perl programming and related subjects, such as web applications and system administration, posted a notice (extract below) admitting the …


This topic is closed for new posts.
  1. King Edward I


    Hash. Your. User's. Passwords. (preferably salt them randomly as well).

    Come on. I'm a complete novice website created (having created, in total, one website, and that was for a uni course) and even I know this. Gah.

  2. Robin Szemeti

    Unencrypted passwords?

    Unbelievable. It would be forgivable of some 12 year old script kiddie ... but given the holier-than-thou attitude occasionally handed down from that site ... someone really does need taking out he back and shooting.

    When you come to think of it .. any site that can mail you your password when you forget it is in the same boat. There is simply no good reason to ever store anything other than a suitable hash of a pw.

    Massive fail on that one.

  3. Anonymous Coward
    Thumb Up


    "Hash. Your. User's. Passwords. (preferably salt them randomly as well). [...] I'm a complete novice."

    Yeah, and I'm one of those PHP devs that perl devs like to sneer at, and I knew about hashing and salting passwords from ... what ... day three of my self-taught course in not being a complete web twat.

    Here's to not being an expert and therefore having to engage one's brain.

  4. Jach

    Smug Mode Activated!

    Ya know, just 'cause it's Perl this time instead of PHP. :) (Yes I know language doesn't really matter if you know security and blah blah blah.)

    On that note, here's some code to generate and rip a combined salt+hashed_with_salt_pass code, in PHP of course:

    function get_salt($hash, $salt_length=10) {

    $salt = substr($hash, 0, $salt_length);

    return $salt;


    function create_hash($plain_text, $salt_length=10) {

    $salt = substr(md5(uniqid(rand(), true)), 0, $salt_length);

    return $salt . sha1($salt . $plain_text);


  5. John 62

    I know PerlMonks is very much more than it's Seekers of Perl Wisdom function, but I think that's what most users originally joined for (and a few stayed for the other community features). Hence much PM traffic went to Not to mention that even before Stackoverflow, with the lack of momentum for both Perl 5 and 6 and the inexorable rise of PHP, Perl was losing mindshare and hence the monastery was pretty much only for the masters of the deepest Perl secrets and initiates who only had Perl problems because of legacy code.

    Anyway, my point is that Jeff Atwood, who co-created wrote several articles about plaintext passwords a long time ago. Then again, someone guessed his admin password for stackoverflow (or was it codinghorror, can't remember).

  6. CD001

    One thing....

    I think there's only limited benefit from hashing (or AES encrypting) password's IF the rest of the user data is stored in an unencrypted format... I mean why protect the key if the data that key is supposed to protect is plain text?

    Granted, if the punter is using that password on multiple websites then yes, you are preventing access to that password... but really, any and all "personal" data in the db should be encrypted.

  7. MrWeeble

    Re: One thing....

    Not really.

    Given the webserver needs to access that data to perform its actions, then the decryption key would have to be on the server itself, and then once the server is compromised it is only a slight annoyance to the hacker. It would only be beneficial had the database been compromised without the rest of the server, but this would add a performance hit to remedy a marginal case (if your DB engine has a vulnerability severe enough to serve up the entire contents of your database, then full system access is probably not very far behind).

    The point of hashing passwords in the way suggested, is that it the hash function is one way, so even the legitimate administrator of the site has no access to the original password, all they have is the result of a hash of the password (and usually some kind of seed text to make dictionary lookups more complicated).

    This is because the site never needs to know the cleartext password; all the site need to know is if performing the hash function on the password entered produces the result stored in the database, if it matches, then it grants access.

  8. Anonymous Coward
    Anonymous Coward

    Re: One Thing ....

    "I mean why protect the key if the data that key is supposed to protect is plain text?"

    Security is about boundaries and layers.

    If I can get read-only access to cleartext passwords, then I can kill your app. If I can get read-only access to properly salted hashes, then I can go soak.

    "any and all 'personal' data in the db should be encrypted."

    A common problem amongst IT security folk is assuming that every web app should behave like an online banking account.

    I am a member of an icon sharing site. I want my password protected so I don't get my social wibblings and connections torched. I don't, however, want the company to spend hundreds of thousands of dollars creating the digital equivalent of fort knox: I want the site to be economically viable.

  9. Anonymous Coward

    Re: One Thing

    Passwords and credit cards need to be encrypted in any database.

    Any other information is useless for most purposes.

  10. ysth


    The site has reset the passwords of those users whose passwords were publicized by the crackers, not those of all users. While we'd like to have done so for all users, getting the notification emails out to just the more at risk group is proving to be quite a hassle.

  11. Nano nano

    Well, you should never trust people ...

    ... who don't know the difference between "your" (YR) and "you're" (UR) .

This topic is closed for new posts.