When mobile app connects to back-end and requests the data, back-end should be sure that requestor is one it pretends to be. So, we need some way to securely identify the app on a device.

While loking for best practices on mobile device identification against mobile back-end, I have found a set of solutions, from just identifying by device ID to using relatively short living tokens (oAuth2 tokens, JWT tokens or just session IDs)

But all methods I have found include transfer of some reusable strings (tokens) that are vulnerable to interceprion. Reusable meaning that if someone has the string, he/she can use it to act on device's behalf.

Even over https, when user is in some closed environment (say, corporate network), he/she may be required to install additional certificate and that string may be intercepted and used for unauthorized access to user data ("mitm attack").

I can think of the following methos to avoid this attack, while keeping things still relatively simple:

  1. Mobile App, on a device, during initial "registration" call generates public/private key pair. Private key is securely kept on a device.
  2. Public key is sent to back-end, and stored next to device's ID (clarification: it's done once in an identified device lifetime, before any other auth actions that allows act on user's behalf)
  3. On each request device sends short "random" string (GUID, or current time, or something got from back-end), and this string, encrypted with a private key
  4. Back-end checks if the "random" string is random enough (not used before) and if encrypted data can be decrypted with public key to that very "random" string. And, if so, confirms device identity.

This seems pretty simple (both iOS and Android has infrastructure for PKI).

And still secure (not vulnerable to mitm attack, impossible to mimic).

The question is - why it is not widely used (or at least widely discussed)?

Is it something standard, that I just do not know how to name correctly?

Is it known to be a bad practice for some reason?

  • 1
    Although, this is simple, it is not secure, because of 2nd paragraph. When public key is sent to server, server cannot identify who sent the key (legitimate user or attacker). Your solution doesn't solve the task you are trying to solve. – Crypt32 Jan 3 '18 at 10:38
  • Well, the "device" is uniquely identified by that public key. No matter who sends it, it may be attacker, but any other authentication (login/password, for example) will be done in context of this public key. If attacker has login/password, he is not an attacker. This, public key exchange, is done before any other auth actions. By attacker we here should mean the one who is going to steal an identity. It's not hte case in 2nd paragraph here, because it's initial identification. – Dmitry Andrievsky Jan 3 '18 at 11:33
  • 1
    Or I didn't get the attack vector you are referring to. Please provide attack scenario. – Dmitry Andrievsky Jan 3 '18 at 11:38
  • It’s not a real attack vector, it makes little sense in authenticating someone whose identity you can’t verify (since any arbitrary device can register in your system). It can be used just to track particular identity activity, but can’t tell who actually it is. – Crypt32 Jan 3 '18 at 11:57
  • User identity virification takes place after this device identification. Usual attack scenario is approx. the following: user logs in on a device and receives the token (say, session id); then the token is sent with each request to ensure that it is THE device where auth took place; attack: the token is intercepted and attacker pretends to be the user, sending the token and querying for data.. This PKI approach (when no token is sent back and forth) aims to protect from such attack, – Dmitry Andrievsky Jan 3 '18 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.