Update 2/16: castaway patched the system. At least now it's not sent back in plain text. Encrypted would be nice, but it is a huge step in the right direction. Thanks castaway! You can hate me now for using so much bold. :)

I wandered over to the perlmonk user editor page, to post my pic (hi maw!), and discovered that my password is prepopulated. This in part scares me for 2 reasons.

Prepopulating it means that it's easy access for anyone who knows how to form a url and post/get it. That being said, I wouldn't be surprised if a broken JS implementation (or a good one) was developed so that the user page could be loaded in a minimal iframe, or one in the lower bounds of the page, and someone create a malicious form to steal the password. I know that some monks have cute forms that post stuff to the chatterbox, what would happen if a user clicked something cute that did the same for passwords?

Also, what if the page gets cached somewhere? It worries me as there have been viruses in the past that have stolen user cookies, so why not cached pages as well? Since it is in plain text and downloaded from the browser, I'd wager the risk of it being stored someplace more permanent being higher. I know that PM is a non-https site, so we do send our passwords in plaintext as well, but printing it to the page for prepopulation of the form kinda freaks me out a little.

Finally, why are passwords stored in plain text? Shouldn't they be crypted (unix,md5,something) in some form? I know, perlmonks is a community site, but it's a site none the less, which can be broken into. And knowing us all, we reuse usernames and passwords. What if a rogue developer or a cracker got into the site? No need to make their lives easier, right?

I'm just concerned. I know the dev team has a lot to deal with, with server upgrades and performance enhancements. It'd be cool to see this addressed as it is a genuine security concern of mine.

Update fixed title and this: Someone said that the view isn't that it's not like it's we store CC's here. That's fine and all, but this is a real site that gets how many people hitting the site? I directed a friend of mine who is security-wise, a yutz, but a smart guy none-the-less. Does it mean I have to go and tell him, "I'm sorry I directed you there, but if someone one day exploits the site, they'll get your password. you should really change it.."? A user's password is also a valuable thing belonging to someone, and as a site owner who has run sites before, I've been expected to hold the same view, just as slashdot or other sites are expected to do. Even a warning, "your password is stored in plain text" is a step up from what is currently implemented. :(

peace,
-s


Play that funky music white boy..
  • Comment on User Editor Page and clear text passwords

Replies are listed 'Best First'.
Re: User Editor Page and clear text passwords
by bart (Canon) on Feb 15, 2004 at 21:35 UTC
    Irrespective on how safe or unsafe the current situation is, I agree with you on this one thing: there's absolutely no reason whatsoever for the two password fields to contain anything. The scheme on form submission should just be as follows:
    • Both password fields are empty: no change
    • Both password contain the same string with length > 0: new password
    • Anything else is an error.
[reply]

      I was going to say that there should be three fields: old password and new password twice. That way stealing a cookie wouldn't allow you to change the victim's password (without an additional cracking step).

      However, I don't want to increase adminstrative requests because of people who have forgotten their password but still have a cookie.

      Perhaps we could do that after we add a 'password reminder' question and answer for each user...

      But I think the change to special-case empty password fields (and to not pre-fill those fields) would be a pretty simple change.

      - tye        

[reply]
        I was going to say that there should be three fields: old password and new password twice. That way stealing a cookie wouldn't allow you to change the victim's password (without an additional cracking step).
        You could tackle that the other way around. You do have everybody's email address from the time when they requested a user account, don't you? Granted, it's possible that address is no longer valid, but that aside...

        What I'm thinking of, is to send a mail to this address whenever the password is changed, with the new password. That way, the original author can always steal his own account back.

[reply]

      Yes yes, its true. Alas, it ain't quite so simple. Or t'would already be done m'man.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi
[reply]
[d/l]
        At least not pre-filling the password box is a simple step. How hard IS that? I mean that most literally, not sarcastically. What's the work that is involved beyond checking if the password fields are not nil and match?

        How easy would it be to put a disclaimer near the password box?


        Play that funky music white boy..
[reply]
Re: User Editor Page and clear text passwords
by CountZero (Bishop) on Feb 15, 2004 at 20:30 UTC
    So I tried to get into your page, but got a "Permission denied" error.

    It seems there are more safety measures than meet the ordinary Monk's eye. Unless you are already logged in, you cannot access the "edit your profile" page and hence you cannot see someone else's password.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
      Yes, there is (protection). But if there's a way of fooling you to load your own preference page and then submit a form..

      Also, if someone just hard-core breaks in, then it's a worse of position, as all user names have been compromised, inform, how many people that their password has been compromised?


      Play that funky music white boy..
[reply]
Re: User Editor Page and clear text passwords
by castaway (Parson) on Feb 16, 2004 at 08:49 UTC
    The "Don't prepopulate password fields" bit looked pretty simple to patch to me, so I've patched it. With any luck my patch is correct, and won't affect anything else, and some friendly god will apply it....

    C.

[reply]
Re: User Editor Page and clear text passwords
by graff (Chancellor) on Feb 15, 2004 at 22:16 UTC
    The password I use to connect to PM is the random string sent to me when I first joined, so it bears no relation to any other password I normally use in my life (and I generally don't remember what it is -- my browser does that for me -- but I keep that email from PM management, just in case).

    The worst-case scenario if someone steals my PM password? They submit "updates" to trash my user page, user settings and any number of the hundreds of nodes I've posted. If they are really subtle and really nasty, they alter code I've posted in malicious ways. If they are nasty and not subtle, they start using my name to do trollish things, and others start to wonder whether I've become unbalanced (bipolar/schizo/etc), until I figure out what's happening and sound the alarm.

    Would that cause me any personal damage? Not really. All the code I've posted here is also stored somewhere else where I have more secure ownership and access control, and any ruffled relationships can be smoothed once the facts are known. If the website has a reliable backup, then this worst-case scenario would be resolved by locking things down for a bit, fixing things to prevent recurrence, restoring to a state that precedes the abuse, and getting back to work.

    I think whatever risk there is in the PM password setup is limited to damage that may be suffered by the PM website itself, and by the community as a whole that it serves.

    I'm not saying there's no cause for concern -- I'm just saying that there is no reason to feel personally threatened by the risk. PM (the website and the membership in the aggregate) bears the full weight of consequences in the event of abuse. If you or your acquaintences are feeling that you have personal things at stake here, think again.

[reply]
      Yes, but how much damage would destroying the trust that holds this site together do? While a security breach probably wouldn't cause nuclear war, it could potentially destroy this site, and I personally would prefer it not destroyed, thanks.
[reply]
        But you don't need to capture a password to do that. All you need is to capture a cookie. And considering this site isn't using HTTPS, capturing cookies is as hard as capturing a password.

        Abigail

[reply]
      I think whatever risk there is in the PM password setup is limited to damage that may be suffered by the PM website itself, and by the community as a whole that it serves.
      You are an exception to the rule. For IM, I use sporte01. For yahoo messenger, i'm sporty3, but point is, 95% of the time, I use the same login all the time. Having worked for a community site company which ran 3 communities (about the same schema for each instance, marketed different) I found many MANY people to use the same login when they can. Same password, I can't say, since they were encrypted. But point is, your login tends to get reused, 'cause it's just as personal if not more personal as a password.

      Heck,.. I actually get called sporty in real life.. so what else should have I used as a login?


      Play that funky music white boy..
[reply]
        White boy? I mean sporti.. I mean sportay :)
[reply]
Re: User Editor Page and clear text passwords
by Anonymous Monk on Feb 16, 2004 at 07:58 UTC
[reply]
      Yes, the problem was brought up before. Just no viabale solutions were really though tof, other than SSL, which doesn't help the caching issue. :\

      Play that funky music white boy..
[reply]

Back to Perl Monks Discussion