This question is related to this one.

We're busy implementing 5 digit passcode authentication for our app (Android, iPhone), but we're running into a complexity. We're unsure how we can safely identify the device from which the app makes the request. We can send and register the device id (UUID) with the user, but that id is no secret, so anyone knowing that UUID could try to authenticate with the server using the passcode.

The answer in the related question mentions this: "During device registration, the application on the device (be it a phone or a laptop) generates some secret value and sends it to the bank; it also stores it."

That sounds reasonable, but how do we store that secret value on the phone? We could use Local Storage, but how secure is that? Is that sufficient?

Another way would be to set a (persistent) cookie upon registering the passcode. But I'm not sure how safe that is either.

I see this system implemented in many apps, but there's not much information to be found on the web.


You don't need to do anything special here.

Storing the token locally in app storage is sufficient.

It is worth considering periodic token expiry requiring more complete authentication via SMS token, email token, or a username and password.

  • 1
    That's what we're thinking now. Our current plan is to generate an id based on the current time + device id (for unicity) and random string (for unpredictability). This string will then be sent to the server, where it is stored in hashed format. The string is also saved in app storage (unencrypted) and will be sent along with the passcode every time the user enters it.
    – Sherlock
    Nov 16 '15 at 16:31
  • @Sherlock UUIDv5 or GUID. Easier and assured unique. You could also generate a secure session token the same way session cookies are generated on the server and send it to the client on first activation. Nov 16 '15 at 16:34
  • @Sherlock that makes me think: what's your plan for first time activation? That should require an SMS token or email token or something, otherwise it's a big loophole. Nov 16 '15 at 16:36
  • 1
    The user has to enter his usual credentials, i.e. login and (strong) password, the first time he uses the app. He then gets the opportunity to enter a passcode for easier access with future use.
    – Sherlock
    Nov 16 '15 at 16:37
  • @Sherlock good stuff. The PIN is a convenience for quick access on an pre-authorized device. I like it. Nov 16 '15 at 16:39

You pose and intriguing question, though there is not one answer for this I suppose I could aid you in giving you a few suggestions as a food for thought.

1, use hardware serials? I know this is not always possible on certain plantforms but I thought I would mention it.

2, UUID, use this and your own ID you generate, encrypt this in the database (or hash it) if you create a good enough alogirthm you can create your own token based off the UUID and send it over a secure connection.

3, phone number, using a mixture of UUID and the devices phone number you can create a nice secure ID.

From what I can tell you are trying to use a very standard method which is not far from the use of a normal username/password the only difference here is you are trying to create the username for them. in most cases people can easily find out a username and try to brute force it, though you should always use an IP fail2ban.

There is an endless array of potential solutions to this, I suppose it just depends on the data you are trying to protect and how you are transfering / storing information.


So you need a shared secret which is unique to the device. What about fingerprinting the device? ie computing a hash based on the hardware confuguration of the device. These are considered robust and reliable for devices where the hardware is not hot-swappable. In fact, HSMs and CA software use this as part of their tamper-resistance.

Googling "mobile device fingerprinting" gives a pile of interesting results.This academic paper in particular caught my eye. From the abstract:

We demonstrate how the multitude of sensors on a smartphone can be used to construct a reliable hardware fingerprint of the phone. Such a fingerprint can be used to de-anonymize mobile devices as they connect to web sites, and as a second factor in identifying legitimate users to a remote server. We present two implementations: one based on analyzing the frequency response of the speakerphone-microphone system, and another based on analyzing device-specific accelerometer calibration errors. Our accelerometer-based fingerprint is especially interesting because the accelerometer is accessible via JavaScript running in a mobile web browser without requesting any permissions or notifying the user.

  • I feel as if this disregards the secrecy aspect. Finding a unique value for the device isn't the problem, making this unpredictable is. If using the same algorithm as proposed in this solution, it's easy to attempt logging in with the passcode without having the actual device.
    – Sherlock
    Nov 16 '15 at 16:34
  • If you use fingerprinting, you don't need secrecy, that's the beauty. The unpredictability comes from physical differences in the hardware that are very very hard to spoof. Every time you want to authenticate the device, you run a test on the physical hardware and collect the fingerprint again. Nov 16 '15 at 17:12
  • It's like how my iris scan is not secret, it's on government record, but it's still considered a reliable way to authenticate me at an airport. Nov 16 '15 at 17:15

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