I have kind of a unique usecase:

  1. Phones that are used to connect to the app might be shared
  2. Connections are very unstable (sometimes no connection for half a day)
  3. Data should be accessible through the interface only by an authenticated user
  4. The data should be accessible after the first login for each user
  5. Users are not really tech sure

PWAs use JavaScript and therefore do have a restricted possibilities for encryption.

My current setup is

  1. angular app with pwa possibilities
  2. PouchDB with remote CouchDB sync for data

I feel like it is not a good idea to store user credentials on the device even if they are encrypted, especially when using JavaScript.

Is this even possible to achieve? And what kind of flow would you recommend. I thought about creating a unique (short, four letter) token that the user has to remember when logging out. It is stored encrypted together with the username. This token in combination with the username can then be used to relogin as long the application is offline. As soon as the app is online again the user is asked to login with its real credentials. If this succeeds the token is deleted and a new one is created (and shown to the user) when the user logs out.

1 Answer 1


You are correct that storing the users password on the device to authenticate against is not a good idea. When you say "Encrypted" I'm going to assume you mean "Hashed" for the password - If not then that's an entirely different conversation!

The reason for this is that if the hash is stored for offline authentication then the password can be brute forced without a request hitting your server, meaning any brute force protection you have is redundant.

The best thing to do with your requirements would be to have a pin code to login, like you suggested. You can encrypt the users data with their username & pin code meaning only they (or someone brute forcing the code) can decrypt it.

As for regenerating the pin on every successful online "session" in the app: The scenario it protects against is if a malicious user get's the pin code, logs in & views the data, gives the phone back, real user logs in etc. and malicious user somehow get's the phone again. The key point here is it needs a malicious user to have the unlocked phone multiple times to be of any value.

If this is a possible scenario then by all means do this. Just know that it severely impacts usability as the uses WILL forget the key, it is inevitable. This will mean being unable to login offline. If instead you user a user generated key (like banking apps etc.) then this would solve the issue.

  • I actually thought about encrypting password and username with the stanford javascript encryption library. But as far as I've read has JavaScript (and clientside encrypting) flaws that might get exploited and on the otherhand the encrypted data is accessible in the browser itself which I don't like. Jan 20, 2020 at 16:56
  • And you are right. I don't need multiple pin codes. Thanks! Jan 20, 2020 at 16:57
  • @PascalZaugg A general rule of thumb - No client is secure. If there is data on a device that a malicious user has access to, you should just go ahead and class that data as compromised. It's only a matter of time until it is if the user is determined enough! As for encryption - You can use CryptoJS - As far as I know this a secure library but please do your own research into this as I have only used it a small amount for hashing.
    – Jack
    Jan 20, 2020 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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