in reply to What happened?

I don't get it... why were the passwords in plaintext? One would think the powers-that-be behind this site are all perl gurus, but this is a really bad nooby mistake. It's pretty embarrassing actually. Once the encryption part is fixed, the login page should probably be changed to use https, too.

And what about pair.com? The server is on their network, right? What are they doing to assist?

Replies are listed 'Best First'.
Re^2: What happened?
by cLive ;-) (Prior) on Jul 29, 2009 at 23:35 UTC

    Who the hell stores passwords in plain text - especially on a programmers' web site? I knew this place had its flaws - hundreds of SQL queries per page view, extremely slow page loads (25 seconds to process my votes on this page's nodes), but really. I kept passwords unhashed for about the first 6 months I was programming. This is up there with using strict and warnings. Cannot... comprehend... stupidity...

    Why not just make this site static for historical reference and redirect everyone to Stack Overflow? The only thing I miss over there is the chat sidebar.

[reply]
Re^2: What happened?
by goibhniu (Hermit) on Jul 29, 2009 at 20:53 UTC

    On the Other Hand, the fact that the login page for PM was not https made me go *shrug* and pick a unique throw-away password from way back when I first created my account.

    #my sig used to say 'I humbly seek wisdom. '. Now it says:
    use strict;
    use warnings;
    I humbly seek wisdom.
[reply]
Re^2: What happened?
by ysth (Canon) on Aug 03, 2009 at 00:36 UTC
    Since every request authenticates by cookie, everything would need to be https, not just the login page. And as far as I can see, that ain't gonna happen.

    Update: or, as tye says, we'd do something quite different with cookies.

    --
    Online Fortune Cookie Search
    Office Space merchandise
[reply]

      True, for our current cookies.

      But the cookie shouldn't depend on the password itself. The cookie should be more like a cryptographic hash of something including the hashed password. So sniffing the cookie would not get you very far. You'd have to learn the "secret" string and then reverse a hash function and that would then only get you the hashed password.

      The 'login' page should be https://. I've long wanted that. That'd also mean getting rid of the "login nodelet".

      Also, a good password hashing function takes significant CPU time. There is a balance to be struck there. Making op=login a very convenient denial-of-service attack point is a bad idea. We might want to implement a "you recently tried to log in (from this IP address or for this username), please wait before trying again" response, which means we only need to worry about attacks from botnets. Surely that would never happen. /:

      - tye        

[reply]

        I'm pretty sure you are aware of this, but to avoid confusion from people reading this later...

        You'd have to learn the "secret" string and then reverse a hash function and that would then only get you the hashed password.

        If we are really talking about the cookie being a cryptographic hash of something and a hashed password, the phrase reverse the hash describes an extremely hard problem. Reversing any cryptographic hash should be computationally infeasible.

        G. Wade
[reply]

In Section Perl Monks Discussion