Reputation: 5487
I am working on a EDIT: mobile web app which displays some sensitive information and requires a login which stores the members username and password in a HTML5 Session. The username and password are currently stored in an un-encrypted state for the reason that we need to use this username and password on each page load to access the clients remote web-service.
EDIT: After a security review our client raised the following concern:
"There is the potential that Session Storage information can get stored on disk (e.g. on a browser crash). For this reason no sensitive information should be stored unencrypted in session storage. User ID’s and session tokens can be stored since session timeouts are implemented however storing of passwords/PINs is not recommended."
What would be the best/most secure method of encrypting and decrypting sensitive data stored client-side?
Thanks!
Upvotes: 14
Views: 30344
Reputation: 11338
More recent browser versions should support Web Crypto API.
1. See the live test page if you browser works
2. The w3c Webcrypto API description
3. Mozilla Developer Network Info on WebCrypto API
Upvotes: 2
Reputation: 29
Storing sensitive user credentials are really not a good design. Instead generate a authenticated token from server using, say, sprint framework. You can then store the same in localstorage using the Web DB Security module.
Upvotes: -1
Reputation: 1
I work on an application that faces the same problem. Security is important for this application because it allows users to build personal trees (or nested lists) and to store them on the cloud.
My solution is to encrypt the password stored on the client side with another password generated by the server for each user.
Upvotes: 0
Reputation: 1
I have to say if your creating a session data 1 is that not,- stored on the server not client side thus no one sees the session data or at least it should be done that way via asp, or php, ect so have the app require internet and retrieve the info from a web server and don't store it on the client side. 2 if this does deal with client side like dealing with streaming a video, or images or you have to create some files on the client side storing the key on the clients mobile device is the only way. Thus either have the key with a short ttl to decrypt the data, the key given through some form of authentication or certificate, or a key installed from your main office and encrypt the device in case they loose it. I not found and encrypt function I like to suggest yet for you.
Upvotes: -1
Reputation: 7685
For anyone stumbling upon this question, Stanford has a crypto project over at http://crypto.stanford.edu/sjcl/. I have not used it myself in production, but am busy investigating it and so far it looks promising. Hope this helps someone.
Upvotes: 8
Reputation: 61
Was researching this topic myself recently. I think by now we do have some proven JS encryption libraries see here and here.
Now the question is where to store the key. Storing it on the client side would be the same as storing the data with no encryption at all. And having the user enter the key all the time would defeat the purpose.
Maybe you could ask your server to generate a new key whenever you create a new session. (Make sure to use HTTPS when making this request). If the session expires, the user has to enter username/password again and it would be encrypted using the new token. To decrypt the key you have to make a (secure) request to your server (passing in your session id) to request the key, which then can be used to decrypt username and password.
Now this still leaves open the usual vulnerabilities such as cross side scripting or session hijacking, but at least the user password is not stored in clear text on the client side.
What do you think?
Upvotes: 2
Reputation: 16345
David Dahl, a Firefox engineer, has a prototype Firefox extension, domcrypt (repository on github), that provides Javascript access to Firefox's NSS (Network Security Services) APIs. Since Chrome also uses NSS, providing the same API is probably straightforward for it as well.
He's pushing Mozilla to evolve it a bit more for eventual inclusion within Firefox; we'll see what happens.
Upvotes: 3
Reputation: 17101
Hi instead of storing the username and password, can you not create some sort of "session" with the remote server and instead transmit an authentication token?
Storing a username and password anywhere in the client side gives me the shivers.
Perhaps of looking for ways of storing the username / password safely, look for ways of removing the need to store it at all.
However of course I'm saying this without knowing the full background... I'm guessing there is a good reason to need to store the username / password.
Upvotes: 11
Reputation: 7614
See this HTML5 Web DB Security
client-side encryption libraries aren't mature or tested well enough
...but it's been a year ago, so that could be false already
Upvotes: 2