User: Password:
|
|
Subscribe / Log in / New account

Session cookies for web applications

Session cookies for web applications

Posted May 22, 2008 15:56 UTC (Thu) by i3839 (guest, #31386)
Parent article: Session cookies for web applications

> the performance of doing 256 hashes is also an issue, but it does protect
> against the secret key being lost. Because an attacker cannot calculate a
> valid authenticator value to put in the cookie (doing so would require
> breaking SHA-256), they cannot create their own spoofed cookies.

Mind that doing 256 hashes instead of a couple is to make it more work to guess the password,
so the only reason is to protect weak passwords, nothing else. Normally brute-force attacks
are made impossible by the salt (at other times than login), but when the attacker has read
access the salt is known.

As users don't login often, the overhead of doing 256 hashes shouldn't be noticeable.

Murdoch describes a simpler alternative that achieves almost the same as this more complicated
version at:

http://www.cl.cam.ac.uk/~sjm217/advisories/wordpress-cook...

> Potential fixes:
> 
>   The problem occurs because it is easy to go from the password hash
>   in the database to a cookie (i.e the application of MD5 is the wrong
>   way around). The simplest fix is to store MD5(MD5(password)) in the
>   database, and make the cookie MD5(password). This still makes it
>   infeasible to retrieve the password from a cookie, but means that it
>   is also infeasible to generate a valid cookie from the database
>   entry.
> 
>   However, there are other vulnerabilities in the Wordpress cookie and
>   password handling, which should be resolved too:
> 
>   - Passwords are unsalted [2], leaving them open to brute force, rainbow
>     table and other attacks [3].
>   - It is impossible to revoke a cookie without changing the user's
>     password.
>   - Cookies do not contain an expiry time, so are always valid (until
>     the user's password changes)
>   - There ought to be an option to limit cookies to a particular
>     IP address or range.

Adding a salt is simple. It would also fix his second point, because revoking a cookie is done
easily by changing the salt, although to do that the original password is needed. Or use a
different salt for the cookie hash.

The last point isn't handled by his new proposal either.

The third point, expiry time, is, but only while the attacker has no read access to the
database.

So the main difference is that MAC is used in addition to normal hashing and that expire-time
and salt are used in the hashing, but the principle is mostly the same.

Over all, the main advantage of stateless session cookies is that the server doesn't need to
access the database to know a client's rights. The problem of brute-force attack and
accumulating session cookies can be simply solved by not storing more than one (or a few)
session number per user. Protecting against read-only database access can be done by sending a
huge random value to the client and storing the hash result, instead of storing the number
directly. The cookie is totally decoupled from the user's password, which seems more secure.

With Murdoch's proposal the server still needs to access the database to get the user's
account details (because read access to the database is assumed, including the key used for
the MAC, so it could be forged), and then the advantages of stateless session cookies are
mostly gone.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds