Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re(3): Filtering potentially dangerous URI schemas in <a href="...">

by hackmare (Pilgrim)
on Oct 21, 2002 at 15:20 UTC ( #206864=note: print w/ replies, xml ) Need Help??


in reply to Re(3): Filtering potentially dangerous URI schemas in <a href="...">
in thread Filtering potentially dangerous URI schemas in <a href="...">

I think that you will find that while possible to break an encrypted cookie eventually, it is by no means a trivial task.

If I can display your cookie to you, I can send it to me. If I can get your cookie, I can login as you.

Most Javascript cookies are encrypted at the server using (most likely) an MD5 salt. The ones that are not usually end up serving as a lesson to others about security and web application architecture embarassement.

Here is my password per Petrucio's site...

userpass=hackmare%257ChaY8je3nfzM7s%257C

I invite you to log into my account and send me a message telling me you did it.


Update by Dog and Pony: I can do better than that. I am very sorry for this intrusion, but what better way to prove my point? After all, you invited me into your account. And no, I will not tell you how I did it. Just suffice to say that encryption does not matter in this case. I'd really advice you to change your password fast. I could do it for you, but that wouldn't really help, now would it? :)



Update by hackmare: Very well done, dog_and_pony. I am clearly wrong and misinformed.
I would very much appreciate a primer on where my understanding of cookie security is wrong.
Is it that the cookie is only appearing encrypted on my machine while it is not, or that you know the server salt, or that you used an improved cracklib (mind you the pwd string is not that good), or that you got a cleartext cookie?

Please reply in another post rather than in mine. And no offense taken for your demonstration.


While not impossible, it is much too difficult to do for the vast majority of hackers. If it was not the case, there would be no such thing as cookies or secure web apps. I seriously doubt anyone without a crypto background can do it.

But this does not change the fact that exposing all of us to the risks of cross-site scripting is a Very Bad Thing for us and for PerlMonks's reputation if there is any problem

hackmare.


Comment on Re: Re(3): Filtering potentially dangerous URI schemas in <a href="...">
Download Code
You have been hacked.
by Dog and Pony (Priest) on Oct 22, 2002 at 09:41 UTC
    I apologize for doing the above. I do not usually do stuff like that, and will not do it again. But since I really want this to be impossible to do on this and on any site, I gave this demonstration. All I needed was the above info. Now, could we please ban javascript from this site?
    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
Hacking "explained"
by Dog and Pony (Priest) on Oct 22, 2002 at 11:52 UTC
    I would very much appreciate a primer on where my understanding of cookie security is wrong. Is it that the cookie is only appearing encrypted on my machine while it is not, or that you know the server salt, or that you used an improved cracklib (mind you the pwd string is not that good), or that you got a cleartext cookie?
    Actually, it is none of this. I am sure the password is encrypted and I do not know now what it is/was. I know nothing about the server, much less any salt and have no access to such information. I did not use any tools besides a browser. And the only thing I got was the string you provided me with.

    What you missed about cookie security is simply this: if you browser needs certain information to remember you and keep you logged in, then my browser can use the same information to log me in as you.

    This is why user supplied javascript is insecure on a site like this, because I can get that information about you and send it to me. Javascript is generally not insecure in this way, and even though I rarely use them, I do not disapprove of js as such - used right, it is fine. What we have here is the unlucky combination of user supplied javascript that is not filtered and a login that doesn't time you out or take other measures to ensure that you are you. So generally, such as warning as Petruchio's is also uncalled for, it is only valid for this site and other sites that allow this. Keep js on for any other place if you want. :)

    I do not wish to change the login and cookie thingy - it is fine if we just remove the scripts. And it is safe in other ways, meaning that it is as hard or harder to simply guess your cookie without information as it is guessing your password in the first place.


    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.

      The scheme could be at least slightly improved without a total change though, by using information such as the user agent string and other headers from the HTTP request to influence the encryption, so that it would at least be more difficult to use stolen cookies.

      (Note this is orthogonal to the Javascript banning question. Whether cookies get hardened is irrelevant to whether JS should be filtered.)

      Makeshifts last the longest.

        While using other information might help, is there any reason an evil script won't be able to send your user agent, or any other information about your browser to it's author? So instead of just stealing your cookie, it'll report the user agent, and anything else required to fake a logged in session. The only thing that couldn't be faked is the IP address, but you can't do sessioning based on IPs, as often there isn't a one-to-one mapping between users and IPs.

        That said, I think it's a bad idea to try to outsmart hackers - there's always going to be one smarter than you thought. Any reason why not to bad JS from the public forums?

        -- Dan

        Funny, I mentioned exactly that example when post-discussing with hackmare. :) Mix the User-Agent with the pw before encrypting and the attacker must use or simulate the exact same browser. Just obscurity, yes, but better than nothing. :)

        Using IP, as some would suggest, is generally a bad method, as it changes (sometimes every request) for lots of people.


        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
Re: Re: Re(3): Filtering potentially dangerous URI schemas in <a href="...">
by zigdon (Deacon) on Oct 22, 2002 at 14:01 UTC

    By the way, just to make the point, it's very easy to crack hashed passwords. This password was hashed using DES (not MD5, which is harder), and took a mere 21 hours to crack. msg me if you really don't believe me that I got it.

    But it doesn't matter how long it take to crack passwords. Since it involves NO manual effort, I could have left it running for weeks, until it eventually cracked. Saying "it's too difficult to do for the vast majority of hackers", is just plain wrong. It's very very very simple to do.

    That's why you never want your hashed passwords reveiled. Aside from the fact, as dog an pony showed, that sometimes you don't need to crack the hash in order to use it. Also, do you really keep seperate passwords on each site you go to? A lot of people don't.

    -- Dan

      Cool! I'm impressed with the level of effort!

      Well, at the very least, after this exchange on which I have been shown wrong on every point I have made (except the need to disallow user-supplied javascript), I now have plenty of ammunition to back up my future arguments about the ease of cracking passwords based on the wrong mechanism.

      Thanks for going through the trouble to be rigorous on this.

      hackmare.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://206864]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (9)
As of 2014-12-18 07:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (44 votes), past polls