Security Remember Me Functionality

[jcox1]

First off: using Seam and loving it.

Now for the problem. I've got the authentication stuff working fine, it was working under 1.5. I'm using 1.6 and cannot get the rememberMe functionality to work. I'm setting that value to true via a <h:selectBooleanCheckbox value="#{identity.rememberMe} /> in the login form. The identity value is getting set to true by the time it gets to the authenticate method, but I cannot tell any difference in the login behavior. I cannot tell that anything is getting remembered anywhere.

The documentation is pretty sparse on this topic (remember me is not mentioned at all). So, a little guidance would be appreciated.

Thanks,

Jack

[hstang]

From what I gather quickly looking at seam's source for remember me, it appears that that the username is stored as a cookie when you are authenticated. This happens if you set the rememberMe attribute to true, like you did with the check box. Verify that you have a cookie name with "org.jboss.seam.security.username". If you do, then your Identity instance will remember the user name.

[hstang]

Just wondering whether it's possible to extend the behaviour of the Remember Me to automatically authenticate the user after they have selected the "Remember Me" service rather than have him or her re-enter their password.

Perhaps store a cookie of the following format:
username + expiry + hash[username + expiry + password]

Then upon cookie retrival, validate expiry, obtain password from username, re-calculate and validate hash[username + expiry + password]

[jcox1]

I was hoping that the functionality worked as described in your second post. That's how I'd like to be remembered.

But, it seems that to do that you'll need a second authenticate method on your authenticator component since the password will be unrecoverable from the cookie, and the current authenticate method requires that the password be present.

I'm also assuming that the expiry in the hash is acting as the salt value for the hash.

I guess I'll need to dive into that code and see if there's a way to make that happen, or just wait on the good people at jboss to add the functionality.

[shane.bryzak]

I suggest you post a feature request in JIRA, that way we'll be forced to deal with it one way or the other :)

[hstang]

done.
http://jira.jboss.org/jira/browse/JBSEAM-863

[christian.bauer]

From a security perspective, this is not a good idea. I can steal your username and password from the cookie with a bit of Javascript. The only requirement for that is that somewhere in the web application, user input is printed on the webpage unfiltered (e.g. on a registration screen, there is an "The address $email is not valid." error message and $email comes form a form field.)

I make you click on a link I prepared and redirect you with a POST and some malicious payload to the vulnerable registration form. My POST enters Javascript code into the form that gets then printed onto the webpage in the error message. In that Javascript, I read your cookie and send it to my server.

This is known as cross-site scripting and there are many variations. Short story: Do not trust the client, do not store sensitive information on the client.

The best "Remember Me" feature is something similar to what Amazon is using: A username cookie is stored on the client, and the web application welcomes the user with his real name and also shows the remembered shopping basket. However, any sensitive operation (editing the shopping basket, buying stuff) requires re-authentication. This combined with an application audit for XSS holes is a good strategy.

[christian.bauer]

Furthermore: Today, clients can fill out login-forms automatically. It is a much safer approach:

a) the user decides when he wants to store sensitive information on the client (e.g. not on a browser in some internet cafe)

b) the user has a clear warning and a message (Do you want to store that login information?) that he has seen before, not some obscure Remember Me checkbox with an unknown implementation he can't control

c) the user can apply local measures to improve security, for example, my remembered login form data is stored in a master-password protected wallet (Safari + OS X)

d) its much harder for attackers to abuse this functionality for fishing, you'd need DNS spoofing to get the victim to a malicious webpage with a faked domain, so that the client auto-fills the attackers form

Having said that, we might add the "trusted client" Remember Me to Seam, but only with big red warning lights.

[jcox1]

Christian,

I'll have to agree and disagree with you.

First, I agree, never trust the client, there is all manner of bad things that can be done by the client or done to the client to have it expose confidential information.

Next, I'll disagree that the proposed scheme would allow an attacker easy access to the user's password. If a secure hash (like SHA-256, SHA-1 or MD5 [which has some issues]) is stored in the cookie it would take some extensive work (like searching an answer space that is 2^69 big on SHA-1). I don't think hstang explicitly indicated a secure hash, I just assumed it. The inclusion of the expiry time in the hash prevents it from being attacked with a dictionary attack because the salt adds sufficient randomness. On average the attacker would need to compute 2^68 secure hashes, that will take a while.

Also, for useful features like site personalization, having the user re-enter their password each time they access the site would greatly detract from the value of the feature. Most people just wouldn't use it.

[christian.bauer]

There is not much difference between getting a valid hash that I can use to log-in to your application, or a cleartext password. I have access to your data.

[christian.bauer]

And for site personalization, that is what I described as the "Amazon" approach. This is what we currently allow, you just need the username for that and then force re-authentication if the user wants to do more and modify some sensitive data.

[hstang]

I'm not sure how you could recover the password in plaintext, as it is hash-ed along with other attributes. As Jack has mentioned, the most clever attack on the most secure hash algorithm we have available today (SHA-1) would take ~ 2^63 steps to find a collision, which is barely feasible.

Now I don't have to steal the password to gain access. Just equally effectively, I just need to gain access to the cookie with cross-site scripting to gain access. Maybe then you can add an additional IP address attribute to the hash content as a precautionary measure. However, this approach fails if the malicious attacker is on the same network that you are on.

[gavin.king]

Attacker does not need to recover the password to login to the application. All they need is the hash, which is right there in the cookies. Sure, you can try to timeout the hash after some period of time, but this is silly because (a) a short timeout means that the whole functionality is useless and (b) a longer timeout means that knowing the hash is as good as knowing the password.

All browsers can remember passwords anyway.

[przemjaskier]

Ok, but in case when only user name is used for creation of the "remember me" cookie, someone can simply create such cookie without performing any "sophisticated" attacks like XSS or cookie-hijacking.

Amazon's approach mentioned by Christian and hashing cookie value can be the recommended approach. Anyway, I added comment to
http://jira.jboss.com/jira/browse/JBSEAM-735
sugesting the cookie creation procedure. Maybe someone can figure out some kind of anti-cookie-hijacking procedure here. Using remoteAddress or host name in cookie creation is a little bit to strict because of plenty of dynamic IPs.

Anyway, I think that this problem should be treated seriously, because some people can get into real trouble when using this out-of-the-box.