I’m building a web app that needs to work offline. The system is built to capture sales transactions. The bulk of the “offline” part is fairly straightforward — I just need to store data locally and sync it when I’m back on the network. So far, so good.
The problem is with authentication. The app will run on a shared machine with a single OS user account. If I’m offline, how do I authenticate the user?
Users themselves do not have any private data that I will need to segregate (i.e., I don’t have to protect them from each other on the client). I need to be able to validate their password so I can let different users login throughout the day even if the connection is down.
One approach I’m thinking of involves caching the password hashes on the client-side in an IndexedDB. Only a limited set of users will be allowed to log in from a specific shared machine, so I won’t need to cache my whole password database locally. Assuming that I have a good password policy (complexity and expiry requirements) in place and the hashes themselves are secure (bcrypt), just how horrible of an idea is this?
Do I have any other options?
This is effectively how Windows (and other systems) work when the machine is not able to reach the domain controller (e.g., you take your work laptop onto the airplane and need to log into your laptop w/o connectivity). Your machine has written down a cache of your username|password pair and will let you in via those credentials even if it’s offline.
I think generally speaking storing the username|password hashes is pretty safe, assuming you’re hashing them reasonably (e.g., using a salt, using an IV, etc). One exposure you’ll want to think through is having the hash file “escape.” If this is sensitive data you’ll want to be exceedingly careful — and this may not even be acceptable, but if it’s not super sensitive data then you’re probably OK: with good hashing I think you should be reasonably (but certainly not completely) safe.