3

Background:

I'm creating a secure web app with the purpose to act as a no-knowledge storage for small data (we're talking a few bytes). Since all the encryption and decryption happens client-side, for the user to be able to manage their secrets, the data has to be decrypted to be searchable and so on.

The server knows an encrypted name and an encrypted value.

All of the data is once encrypted by the client, then encrypted once using a shared secret from SRP and then sent through SSL.

Solutions / concerns:

There's two ways this can be done from what I know.

A: Send both the name and value to the client and let them store it during the session. The names are decrypted and shown, whilst the values remain encrypted. Due to the unsecure nature of javascript and for UX-reasons, this would be just as secure as decrypting all the data and store it. Since the user receives all the values, there's a bigger risk of an offline attack to happen. This also makes it difficult to control that the values never exist longer then the session (for example how iOS Safari stores the webpages in an active state even when the app is off).

B: Send only the encrypted name and a token. The names are stored and shown to the user in a decrypted form. Whenever the user would like to see the decrypted value, a request is made to the server which sends it. The value is never stored on the client. This limits the risk with offline attacks - since the user will never have all the values stored at once. The worst scenario would be one value stored. The problem I see with this is that there will be a considerate increasing amount of data sent through the internet - which might be a greater risk than storing it offline.

Question clarification:

Is it safer to store the data on the user's device without being able to revoke their access to the data

or

Send valuable data many more times through the internet?

  • 1
    You haven't described the threat model. Who are you trying to protect the data from? Is the user allowed to see the unencrypted data? Are they allowed to see it, but you're trying to prevent them from copying it? What kind of attacks are you trying to protect the attacker from performing? – Steve Sether May 22 '15 at 19:18
  • @SteveSether that's a good question. The users are the owners of the data - so naturally they are supposed to see the unencrypted data. However I, on the behalf of the user, want to keep the data within the application and control how the data is stored - so that the data never exists beyond a valid session. If they would copy it, then that is up to them and I chose not to take that as a risk. Attackers are never supposed to be able to retrieve a clients data without the clients knowledge as in the only "acceptable" attack is offline if the data persists on the device without the user knowing. – Alex May 22 '15 at 20:02
  • I'm not clear on how you avoid the client end ever storing values. Even if you use javascript queries to retrieve the data when necessary there's no guarantees the browser isn't going to store the page in some way. – Steve Sether May 26 '15 at 14:06
2

As long as the data travels inside a properly configured SSL/TLS connections, there is no security issue regarding the increase amount of data sent through the internet, the only downside would be an increased load on your server.

If you cannot trust local storage, then fetching the data from the server when it is required seems the best option from a security point of view.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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