Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:0

Sniff Those Cookies!

posted by Krow on 09:31 AM May 3rd, 2001   Printer-friendly   Email story
isaacrab writes "A friend of mine runs a Perl-based message board. I've promised to help her upgrade user authentication, which is currently your basic lame cookie-based clear-text password setup. So I need to educate myself on the alternatives. I know a little bit about encryption, but I lack even a script-kiddy's practical knowledge.

Slash seems to be a good place to start, but I don't understand why the system is a secure as it seems to be. Hashing may make data harder to sniff, but not impossible. Transmitting an MD5 key instead of a password may protect the password itself, but isn't the key also worth stealing? Can somebody help me see the big picture?"

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.
  • by Anonymous Coward
    Hash-based authentication methods work via a challenge-response mechanism. The server sends a random challenge. The client combines the random challenge with the password, and computes a one-way hash. The client sends the hash to the server, which performs the same computation. Iff the client's supplied hash matches the servers computed hash, the authentication succeeds.

    The hash which the attacker could see on the wire is only useful to him if the server supplies the exact same challenge when the attacker tries to (falsely) authenticaticate themself. If the challenges are "random enough" and come from a "big enough" range, an attacker has a vanishingly small chance of seeing a repeat.

    For a more technical description on this and all sorts of wonderful other security-related things, read Bruce Schneier's "Applied Cryptography".

  • If you're going to store an authentication hash on a cookie on the client machine, you need to decide how you're going to calculate the hash.

    One danger is that someone could copy the cookie and use it on another machine. To stop this, the hash could be calculated using the client's IP address, username and a secret key. You can find a fully coded example in the O'Reilly mod_perl book. Unfortunately, many users have dynamic IP address, so this would block access for those valid users as well as cookie thief.

    It might be worthwhile storing a list of users that have been denied access because their IP addresses are not those stored in the hash, but who subsequently re-logged in correctly. This list could be then used as a trigger to issue a lower-security hash, not based on IP address - maybe on User-Agent, username and a secret key.

    Any other ideas? Could anyone provide a simple description of how the Slash cookie works?

  • Currently, the Slash cookie is just an MD5'd version of the password. That's all.

    The reason we did not calculate based on IP or something is exactly what was said here; it causes some significant problems for users. SourceForge gets around this by recording the user's IP address, and then checking to see if it is in the same class C or class B or something. Still, these methods aren't great. For one, many people (like myself) are quite mobile and access the site from many different locations, and we like not having to re-log-in each time. Perhaps we could allow the user to select whether or not to authenticate with IP, or with Class B, or with Class C, or with password alone. Or something.

    Bottom line: yes, your cookie can be used to get into your account, if it is stolen. It would be nice to change this at some point (and it wouldn't be hard to do, once we decided how to do it) to improve the security. Buy really, we had very few complaints about the fact that Slash uses passwords in cookies; most complaints were just that they were clear text, both in transit and in the database; that is, they were more concerned about the security of the password than of the account.

    So anyway, I think the best solution might be the one outlined above -- allowing hashing with IP or without (maybe even make the B/C options available, but that would probably just confuse people).