Asymmetric crypto to store credentials in HTML LocalStorage

Question

We are developing a Mobile web app where the users want (and it is a non relaxable requirement) to be logged for a very long time.

The solution we are developing has a web-client part in HTML+JS and a middleware in Java. Storing the users credentials in the middleware is not an option because we do not want to have a single point where some Administrator can get ALL the credentials of the users. So to be short these are the requirements:

1. Remember me for a very long time
2. Middleware cannot store users credentials
3. Auth systems in the Backend of the middleware cannot produce a long time session token
4. We want to protect the users credentials more than the application access

We know very well that storing credentials in the HTML LocalStorage or Cookies is a very bad security practice, but:

1) Users know that they have a very long time "remember me" and it's their responsibility to log-off (Security vs Usability)

Obviously storing the credentials in plain text in the HTML LocalStorage is not an option because XSS attack can steal the credentials, so we have designed a solution and we want to discuss its security here. A small notice: we'd like to discuss it under a real point of view not an academic vision ;)

a) users put their credentials in a web form b) a JS lib encrypt the credentials with a RSA Public Key (1024) and put the encrypted payload (EP) in the LocalStorage c) the EP is sent to the middleware which decrypt it with the private key and authenticate the users to backend system(s) (there could be many backend system with SSO) - there is a session id to avoid decryption on every call (when the session expires the client resend the EP) d) if EP exists in the client side, the client send it and authenticate again the user e) if the user want to log-off, the client deletes the EP and give the login form to the user

The security point are:

a) on the client side there is only an encrypted stuff with an asymmetric algorithm ==> none can decrypt it b) we consider much harder for an Administrator to put inside the middleware than to steal credentials on the disk c) Every N months we renew the RSA keys and all the users must reauthenticate

The only attacks I can image are:

a) a browser plugin that steal the credentials before the encryption ==> this is true for ALL the web auth forms b) a replay attack: stealing the enc payload permits to authenticate impersonating the real users ==> this is a problem, but the credentials of the users are safe and this balancing the very long rememberme (same problem of very long session)

I cannot imagine other kind of attacks.

I am very opened to all the opinion to improve the security of our solution (but usability is very important...)

Answer 1

It sounds like you're making this more difficult than it has to be.

Clearly a random, server-issued key which corresponds to a server-side data element is by far the best solution, and in practice the only solution that any reputable organization employs. But since you want something different, here you go:

Upon login, you encrypt the login information server-side, with salt and some HMAC (and possibly a timestamp), base64 encode the result, and there's your persistent token that you issue to the client. Ideally you should also tie the login to the device somehow; perhaps some sort of static device ID that gets sent to the server and encoded into it.

Then when you need to re-authenticate, your client passes this token to the server, which your server will decrypt, authenticate, and then issue your app a session key as normal.

It's not quite as good a solution as a random, opaque authentication token (which is valuable only as it corresponds to some server-side datastore), but you said that this is impossible for some unknown reason. I would argue that if something as simple and useful as this is impossible, then you're using the wrong software.

As for using asymmetric crypto and browser-based RSA for storing authentication tokens, I can't come up with even one scenario where this is appropriate. But sometimes complexity for complexity's sake has it's own allure.