5

I am looking into writing an API that will be accessed by mobile devices (We also own the mobile application, there are no 3rd parties involved).

As part of the login flow we have been instructed to use an email/password registration flow, followed by the creation of a 5-digit pin number which would allow the user access to the application upon next opening the application.

This seems to be at odds with the majority of authentication flows available such as oAuth as there seems to be no indication of using a further pin authentication for login.

There are plenty of applications that do seem to do this however, so I wonder are they rolling their own solution? Or a combination of typical services and then hosting something themselves?

I am struggling with the concept of ensuring the unique device is also tied to the pin in order to authenticate requests correctly within the API.

Pointers welcome, but for something that I see is quite common in mobile applications, there seems to be precious little detail out there with regards to the security aspects of this kind of authentication?

With thanks

Improve this question
3
  • Can you clarify the flow? This is how I interpreted what you have now: User manually enters in email/password from their mobile device. Now they have full access. Additionally, the user is presented with (I assume an optional) 5 digit pin which they can manually enter in instead of their email/password the next time they want to login in the future? (If that's correct I'm not sure I see the point of the pin...)
    – TTT
    Commented Jun 21, 2016 at 18:42
  • That is a correct assumption, the PIN in this case I guess you could treat as a convenience feature, as opposed to the primary identity authentication mechanism if that makes sense?
    – Cmac 84
    Commented Jun 23, 2016 at 11:18
  • OK, I understand, but I'm not convinced that remembering a new 5 digit pin is much easier than just typing in your username and password again. If it wasn't manual entry of the pin, I think it would make more sense (like a refresh token), but in that case I would use something much longer than 5 digits, preferably something unique like a guid.
    – TTT
    Commented Jun 23, 2016 at 14:42

1 Answer 1

Reset to default
2

I do not completely understand the question, but it seems that you want to know a good solution to implementing this.

To implement this, I would suggest fetching a unique devide ID (Can be IMEI, but can also be some OS-dependent ID), and then concatenate this with the PIN. Then you use PBKDF2 to derive a key out of this.

You then select a number of iterations that are sufficent to prevent cracking the 5-digit pin by bruteforce, but still doesn't take awfully long time to authenticate.

Here you have 2 choices. Either you can encrypt the OAUTH token with the generated key and store inside device storage, or you can implement a verification on the server side, where you verify the PBKDF2 key when a mobile OAUTH token is used. To sense if it a mobile OAUTH token is used, you can set a flag in the login form to detect mobile logins.

A better solution, if your management allows this, is to use hardware-based storage of assymetric keys instead. (boolean KeyInfo.IsInsideSecureHardware();), where the server will verify that the correct private key exist inside secure hardware (by doing a challenge which the app signs using the hardware key). That will make it possible to strictly bind the app to a specific device, and you can skip PIN authentication, as the user's lockscreen is enough to prevent misuse of the app. (and then you give the users choice too, to not have a PIN if they want, by disabling the lockscreen).

Improve this answer

You must log in to answer this question.

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