Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

We blame tye.

by Anonymous Monk
on Mar 22, 2002 at 07:11 UTC ( [id://153507]=monkdiscuss: print w/replies, xml ) Need Help??

Warning: This post is rated R. Adult language and violence .. lots of it.

It was the evening of the first day of spring and, other than the appearance of jc and his ServerPup on national television, it had been a fairly normal one, too. In the Perl Monks IRC channel, ar0n and tye were working on fixing the homenode image upload problem. Eventually, tye lost his 'patients', and left ar0n with the following words of wisdom:

<tye> &displaytype=hack (: <tye> try that ar0n, on your home node <tye> I'm still away
ar0n was a bit confused:
<ar0n> Where on my home node? * ar0n hits tye
So zdog explained it to him:
<zdog>    http://www.perlmonks.org/index.pl?node=ar0n&displaytype=hack
At first, ar0n got real excited about his new toy:
<ar0n> tye!! <ar0n> Rock! <ar0n> Neat!
But someone had access who shouldn't have:
<zdog>    Ha .. your passwd is 8 chars long.
And someone else was quick to realize:
<japh>    No! Don't look at the source! disable! disable!
Some of us became a little discomforted:
<ar0n> !! <ar0n> !! <ar0n> !! <ar0n> !! <ar0n> !! <ar0n> !! <ar0n> !! <ar0n> !! * ar0n hits tye!!!!!!! * ar0n hits tye!!!!!!! * ar0n hits tye!!!!!!! * ar0n hits tye!!!!!!! * ar0n hits tye!!!!!!! * ar0n hits tye!!!!!!!
And others began to laugh:
* japh chuckles <zdog> Hahaaha/
Then all hell broke loose:
<ar0n> GOD FUCKING DAMNIT <zdog> Where the fuck is tye?! <ar0n> At least we have a god around who has access to the database +. <zdog> You can look at everyone's passwd! <Kanji> japh | um, but if the password is there... <Kanji> "You can't edit this node (unless you view source first :-) <zdog> Damnit tye!! <ar0n> TYE! <ar0n> Oh god... * zdog goes to check japh's passwd. <ar0n> Talk about security holes... <zdog> =) <zdog> j/k. * booradley sells ar0n's info on the black market <japh> TYE <ar0n> TYE <japh> TYE <ar0n> If I kick him, will he autorejoin? <japh> ar0n: I don't know. <ar0n> WAIT I HAVE HIS CELL PHONE NUMBER IN MY LOGS <ar0n> HOLD ON <japh> ar0n: HURRY <cow> tye <japh> TYE * cow beeps <Masem> stop beeping! <booradley> sweet merciful crap. <ar0n> 20:11 <tye> ########## if you want me to back the patch out * zdog blames tye. <ar0n> IM NOT GETTING A RESPONSE <japh> THE MAFIA GOT HIM! NOOOO * cow fights the urge to beep again. * Kanji remmbers that for next time he loses his password... <zdog> So how do you people like my passwd? =) <ar0n> CALL HIM <ar0n> SOMEBODY CALL HIM <zdog> I don't know his number. <zdog> Call jc! <ar0n> zdog: scroll up <zdog> Oh, okay .. <zdog> why can't you call? <ar0n> I DID. NO ANSWER <zdog> I'll call. * cow quietly squishes ar0n's Caps Lock <ar0n> Oh, sorry. <japh> fucking bad time for tye to be away... * cow watches all the passwords get eaten.
Finally, things settled down:
<japh> Oh good. Internal server error. <cow> Oh. <japh> The quick way to disable that. <zdog> ar0n got him. <japh> k, good
Some of us became a little happy:
* zdog called. <zdog> I feel special. * japh mumbles <zdog> I got to talk to tye. =) <japh> heh.
ar0n summed it up best:
<ar0n> I think I speak for all, when I say "..." <japh> Yes, quite. <cow> amen, brotha. <zdog> ar0n: damn straight.
It was finally over.
<zdog> So now what? <ar0n> Now I change my password.
Some of you may want to do the same. However, tye did go through the logs and made sure that all of the passwords that may have been stolen were changed, but if you're paranoid ...

And what a mess it was. There are several lessons to be learned here: have a test site, pay your admins, don't code faster than the legal speed limit, and always, always blame tye.

Replies are listed 'Best First'.
Re: We blame tye.
by mdillon (Priest) on Mar 22, 2002 at 17:11 UTC
      Unfortunately, storing the crypted version of the password on the server means that the client has to send the password to the server in plaintext. Either you hide that with SSL, or you accept the fact that you have no real security.

      If you try to protect the password in transit by using something like HTTP digest authentication, then you have to store the password (or some equivalent secret information) in plaintext on the server. Which is the bigger vulnerability?

      And then there's the problem of forgotten passwords. If I forget mine, perlmonks will mail it to me. Not too secure, but handy. If you store crypted passwords, the only option is to reset them to some known value when they are forgotten. How do you know if the person requesting a reset of my password is me, or a bad guy?

        The way I typically handle it is to.
        • store them crypted
        • require that the login page be accessed via SSL
        • forgotten password is reset and emailed ONLY to the email address stored in the database for the provided user id. This doesn't prevent a malicious person from resetting someone else's password, BUT the person who receives the email saying what the new (randomly generated) password is, is the valid user.

        /\/\averick
        perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

          Unfortunately, storing the crypted version of the password on the server means that the client has to send the password to the server in plaintext. Either you hide that with SSL, or you accept the fact that you have no real security.

          If you try to protect the password in transit by using something like HTTP digest authentication, then you have to store the password (or some equivalent secret information) in plaintext on the server. Which is the bigger vulnerability?

        Some excellent points, no_slogan. It's kind of depressing that the current state of the art, as far as anything common enough to be useful goes, relies so much on plaintext passwords. (Although you might be able to get the client to hash the password before sending it over the wire, using a browser plugin of some sort. Provided that you trust the plugin.)

        Is there a better way of doing user authentication for sites like PerlMonks out there that doesn't rely on pie-in-the-sky technology? (Preferably something that doesn't involve shared secrets, which IMHO are just too much trouble.) Having the client hash the password before sending it over the wire is a start, but doesn't help much if the server isn't who the client thinks it is, since the attacker can just play back the password hash at the real server.

        I'd look up some ideas, but my copy of Applied Crypto is at home, and I'm not. Anyone else?

        --
        :wq

        I know I'm coming late to the dance with this, but I've been giving it some thought. When we speak of security, we are usually talking about one or two different things; authentication and encryption. The http protocol isn't really designed for security, it is designed for functionality. Security is left to the implementor.

        Putting aside https for the moment (which really is the best implementation of http when it comes to both of these topics) we need to look at what we can do to fulfill both of these points. In the case of a login, we are actually in the process of trying to authenticate our user, which means there isn't a trust system in place between the two parties.

        My thought about this would be that when a user first subscribes to our system, they are required to provide they're public key. Also, the monks public key is provided on the site. Now, when someone logs in, they first encrypt their pass-phrase (We're talking security here, so let's go all the way) with the monks public key, insert it into the pass-phrase text area and submit.

        PM has its private key, decrypts the pass-phrase and registers it. And, of course, monks must repeat this cycle if they must login. Of course we can still use our current cookie method of remembering who we are to limit the need for this. Beware, however, if we are at a location that doesn't have a tool for encryption, we won't be able to login. If a pass-phrase is lost, a new one can be generated and emailed to the monk using their public key. The system is complete.

        Another way would be to write an encryption method (using the above mentioned key structure) completely in JavaScript, send the PM public key in the client side scripting. OnSubmit, encrypt the pass-phrase, set one of your inputs (hidden or otherwise) to the encrypted password and away you go.

        Sounds trivial, but I'm not sure I would want to try and write those algorithms in JavaScript of VBScript. *BLECH*

        This brings me back to https. This protocol has the two pieces of security that I mentioned above. The authentication portion of https is a safeguard against some site saying they are PM when they're really not and stealing whatever informaiton we are sending to one another. The simplist method of encrypting passwords would be to implement the login only in https without a third party certificate. All we are truly talking about here is encrypting passwords and sending them securely, not authenticating one or both of the parties involved. On most webservers you can allow the server to generate it's own certificate for the sake of encryption, and only if we were going to implement a shopping cart or something similar would the need for a third party cert really be necessary.

        Those are just some thoughts I've had about this topic, your mileage may vary, this offer only good to the first ten callers, some restrictions may apply.

        C-.

      Unfortunately, many sites have to support a "mail me my password" feature. A tech site like this can get away with just sending people a new auto-generated password, but I don't think that, say, Amazon.com could do that. That means they must have the passwords in plain text somewhere.
        A tech site like this can get away with just sending people a new auto-generated password
        Then someone could hassle me by repeatedly requesting password changes on my account. If they did it every 5 minutes, I could hardly use the site at all. The server could impose a rate limit on password changes, like only one per day or so. That would eliminate the full-blown denial of service, but I'd still have to go check my e-mail for the new password, which might be inconvenient.
Re: We blame tye. - I don't
by stefan k (Curate) on Mar 22, 2002 at 10:17 UTC
    So tell me,
    who am I to blame some person who spends his/her time to help running a site that is free (as in beer)? Even if some faults were made. And who are you to post anonymous when you're blaming?

    I Don't want to start any flaming I just consider this a not so very bad thing to happen and I think you should have the guts to stand for your opinion. Anyway, thank you for this little insight into IRC for one who never IRCs :-)

    Thanks tye for all the work you're doing, and thanks to all the others, too, of course...

    Regards... Stefan
    you begin bashing the string with a +42 regexp of confusion

      Just FYI, I know the people behind the posting and saw an advance copy. It was meant in fun. (:

      Update: Yes, it all really happened.

              - tye (but my friends call me "Tye")

        Well, I'm glad you let us in on it. I really thought this one was going to become a BBQ. I'm still left with the burning question 'Did this really happen?' or was this all fiction for our amusement...?

        BTW, someone once told me that the word 'gullible' was missing from all major dictionaries.... of course I ran right out to look it up ;)

      Come on, read it with a smiley in mind. It thought it was amusing. Probably no harm done, but valuable lessons learned. :)

      On a side note, a cow orker today used mv instead of cp when he decided to "borrow" some HTML::Mason code of mine. People started to wonder why our error reporting form didn't work (404 Not found). I suspected he had borrowed the code so I confronted him... "Did you by any chance type mv instead of cp?". He had the window still open and quickly browsed through the history... suddenly his face became red and quiet moaning was heard. "How much did you change?" - "Everything!"... Backups were available though. Hehe...

      I went a bit OT... sorry....

      --
      Dennis "dempa" Sjögren

        Come on, read it with a smiley in mind. It thought it was amusing.

        I didn't mean to sound offending. I actually read it with a smile. Still I wanted to point out that I don't see any reason to actually _blame_ tye. I thought the part about the insight into IRC would make this clear...

        BTW what is a cow orker? *grin* And how could he mv your files? Group writable? And once again the backup lesson learned :)

        Regards... Stefan
        you begin bashing the string with a +42 regexp of confusion

        Backup???? use CVS :)

        --
        My opinions may have changed,
        but not the fact that I am right

How Much XP For That?
by McD (Chaplain) on Mar 22, 2002 at 16:32 UTC
    Bishop, Pontiff, Saint... Scapegoat.

    Pefect, just what I could use around the office. Thanks, tye! :-)

    Peace,
    -McD

Re: We blame tye.
by ambrus (Abbot) on May 01, 2014 at 14:13 UTC

      Advice is inaccurate.

      Time changes all things

        ... for bringing back this thread from the underworld. ;-)

        Cheers Rolf

        ( addicted to the Perl Programming Language)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://153507]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2024-03-19 05:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found