Question

We are making an app on android and iphone. One method is to save password hash in local device and login remote server every time (with token). The other method is to login once and then get the token to communicate with server. The app save the token in device, so if user don’t logout manually, the token won’t expire.
Some teammates think the latter method is better instead of saving password hash in local device. But I think keep token is also unsafe. Could anyone please give us some suggestion?

Answer 1

We probably need a little more detail to evaluate what you’re considering. Either could in theory be built well. There are several things to consider.

First, it is best to have your authentication token expire periodically. This closes the window on stolen tokens.

Authentication should always be challenge/response in order to avoid replay attacks. You should generally not send the token itself. You send the response to a challenge that proves you have it.

Of course you start with TLS as a transport layer. Ideally you should validate your certs. Together, this alone can protect against a wide variety of attacks. Not all attacks; TLS is not magic security dust, but it does provide a very nice “belt and suspenders” defense in depth.

It’s interesting that you’re saving the “password hash.” How are you using this and how are you salting it? In particular, if many people have the password “password1”, will all of them have the same hash? Without TLS, this can open you up to significant problems if you’re sending the hash itself across the wire.

On iPhone, you should store sensitive credentials in the keychain. SFHFkeychainutils makes a decent wrapper around the keychain (I’ve got my beef with it, but it’s ok). Unfortunately, I don’t believe Android has a similar OS-provided credential store. (No, iPhone’s keychain does not protect against all kinds of attacks, but it does provide useful protections against certain kinds of attacks and is worth using.)

You want your protocol to make it possible to deauthenticate a device that has been stolen. That could take the form of the user changing the password, or revoking a token, but the user needs a way to achieve this.

Again, it’s hard to evaluate a broad, hypothetical security approach. Tokens or passwords in the protocol can each be fine. What matters is the rest of the protocol.