The question says it all really. I want to provide a service but I do not want to store any of the data myself in a database. With all the recent news of hacking etc it seems to me that it is nicer that clients have complete control over their data.

The problem is that the data stored is potentially sensitive. What I was going to do was... when a client visits the website there would be a question asking 'are you on a personal computer or a public computer'. If they are on a public computer the site would refuse access.

If they were on a personal computer it would then prompt them to set a password. All their data would then be encrypted with this password. Now obviously this is not too secure. The encryption method would be in JavaScript and their password in plain text so I assume it would be possible for a savvy user to locate the password in the localStorage and access the data.

I feel though that this isn't too much of a problem. If you are using a personal computer the chances of this happening are remote as... someone else would need access to their specific user account on the computer, someone else would need to know about the site... someone else would need to understand localStorage and how to access it. The sensitive data isn't any that will compromise their identity or much else. It just records something most people wouldn't like publicly published.

So really the question is, is localStorage secure enough?

Additional question.. how difficult is to wipe your localStorage? I wouldn't want users to accidentally wipe their data.

Finally - is it even worth encrypting / decrypting their data as if you have the password you can access the site..

  • 2
    Client-side JavaScript is not the best place to be doing cryptography. Any savy user can look at the code and hack into your encryption algorthim and make it so that it doesn't actually do anything and it just accepts the encrypted password.
    – Maz
    Commented May 5, 2011 at 16:27

6 Answers 6


How about just not storing the password at all, not even in local storage? You can use a key derivation function to get a key from the password. With a salt and a reasonable number of iterations this should be decently secure.

  • It would be more secure right if the password was submitted to PHP which then generated the key behind the scenes? Commented May 5, 2011 at 16:31
  • No. The password is given on the client at first. By sending it to the server you increase the risk it can be stolen. Doing the key derivation in JS keeps the secret on client. In every case you should forget the PW shortly after that. But i think it's still pointless -- see my answer.
    – halo
    Commented May 5, 2011 at 16:47
  • Many hackers are quite intelligent...Use Lib bCrypt. Commented Sep 9, 2014 at 15:34

Using JavaScript with local storage is at maximum as secure as (your server plus the connection between browser and server).

If anybody manages to modify your server and serve different JS files or modify (while being transmitted) the JS files sent from the server to the client they can do anything with the data they want.

Additionally: Because the data is on the client you can do nothing to protect the data. On an ordinary server you could e.g. restrict the frequency of access (example for a remote password safe: only 1 password read within 10 minutes). All of this is useless if the data is on the client and all the code working with the data can be manipulated by an attacker.

After all even with localstorage you need to secure your web application! Why doing things on the (hopefully) secure server then? If not why not using a local program installed on the client either?

  • Don't you think the main security issue is if the device gets used or stolen by someone else?
    – Mic
    Commented May 5, 2011 at 19:47

How about getting a key from the server that is used to decrypt the localStorage data?

It could work like this:

  • When a session is established, the server returns a key.
  • That key is used to encrypt / decrypt the data in localStorage.
  • When the user leaves the page, the key is lost, preventing others from reading what's in localStorage.

This should only allow access while a user has an established session.

  • 3
    This wouldn't work to access the data offline though (which seems like a primary use case for localStorage). To use this method offline, you would need to retain the key. Commented Apr 11, 2013 at 18:39

Two issues:

  1. if you store plain text passwords and then rely on the fact that are not likely to be found, it's just security through obscurity. Just store the data in cleartext and rely on the same assumption (still not safe, but no false sense of security)

  2. on most browsers, if people wipe their cache they remove their localStorage content as well. People do not expect to lose important data when they wipe their history and cache.

I think you're overbending what localStorage is meant for. If you want to use a local database that plays well with webapps you could take a look to CouchDB's couchapps.

But don't store the password.


generally its not hard to wipe local storage, but it depends on the browser. You do need to get at the browsers developer tools though (firebug, webkit stuff, etc).

think of it like you think of cookies. You should never keep sensitive data in local storage. passwords, credit card numbers, whatever.

you can always implement some feature to clear the local storage after x amount of inactivity, but thats not going to solve a security problem. Its like an automatic session expire. The same problem applies, if a person leaves a computer and then someone else sits down before the session expires, they can do stuff.


You could use javascrypt. Ask the user for a password that would become the encryption/decryption key

You don't need to store the password, but request it each time the user open the page.
May be store it, if the user wants, and now the implications.

But then to join stivlo's comment, what about:

  1. multiple device access
  2. backup
  3. forgot password
  4. too easy cache clearing

I think you should reconsider the start of the reasoning. Avoid the cloud just because of some recent and sensational events, is a quick conclusion.

Not the answer you're looking for? Browse other questions tagged or ask your own question.