We are wanting to authenticate the user inside a webapp (JavaScript/HTML inside browser) running on a tablet, but want to be able to do this when the device is offline from the network. I realize this isn't super secure environment already, but I don't want to make it less secure by a poor authentication method.

The environment is a web app that runs on iPads inside a corporate network. Users take and share iPads (that's OK) but we need to authenticate that the current user of the webapp is valid, blocking random people/staff that might pick up the device. Network connectivity is not 100% and this cannot be readily improved. Our aim is more validation for audit purposes than security control, we need show that user X performed the action on the iPad.

Authenticating when we are on the network is easy, send a packet to server and get a yes/no response. However if we are offline we cannot do that. I could download all users and password hashes to the iPad, but this seems like a bad idea - I've just exported the password file, this just feels wrong.

The next idea was separate online and offline passwords, but that seems too hard for users. We also considered trusting the login and deferring validation until we are back online, but that has business/application issues. Currently, we're going with normal passwords for main app as normal, but using a visual password on iPads, basically two passwords but presented different so users don't perceive it to be the same. Having two passwords means we can have different policies, controls and audits.

Are there any better ways of doing this?

1 Answer 1


I'm sure you didn't intend it to be so; but this is currently a politically-charged question, as well as a technical one. Some appsec experts believe that crypto implemented in javascript is inherently flawed; and they make some good arguments, only a few of which are inapplicable due to the javascript being accessed only on an intranet, and only on one kind of device.

Authenticating a user on a device with no network connectivity means storing a password hash on the device. There's a lot of clever things you can do with crypto, but you can't get around that. The best you can do is to use a strong password-based key derivation function, understand that this may still leave you quite vulnerable, and use compensating controls: Physical security and policies to make it difficult/risky to extract the hashes from HTML5 local storage and take them home for offline cracking.

This leaves the question of which password hashes you store locally. It sounds a little like you're only interested in non-repudiable actions:

we need show that user X performed the action on the ipad.

If the only reason you're using authentication is for non-repudiation, and a single repudiable action constitutes a complete break of the system, there's not much point to having two separate passwords for each user. If you have additional security goals beyond that, it may be worthwhile to keep two separate passwords; especially if user compliance isn't an issue--and your UI solution for that does sound effective.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .