0

I'm designing a login system for my mobile app where users only need to provide a pincode to authenticate into the app after they sign-up.

I'm more wondering how the backend would work in such a system in general. To begin with, is the pincode saved on the device or server? If it's on the server, then how it's passed to the server? Or how it's associated with the username-password tuple?

Thanks in advance.

  • This is very vague. Can you include more about your architecture? What programming environment/s are you using for this? Is the login web-based or custom application? – bashCypher Jan 15 at 0:35
  • This question is related to web based programming and does not belong in this forum. Also, the answer to such questions could be found easily by searching on the web. Please do the homework before asking such question. – tech_enthusiast Jan 15 at 0:38
  • @bashCypher it's vague to me as well :). I'm developing this for Android in Java/Kotlin. It's mobile app with bunch of backend capabilities including the authentication. Hope it's more clear. – zgulser Jan 15 at 8:41
1

How pin codes are used, like passwords, are numerous and varied.

Sadly, there are still a lot of implementations that simply keep the pin/pass in clear text in a table (DB or Flat) correlated with the User ID.

Better, is a HASH of the pin/pass is kept correlated with the User ID. That way if the DB is compromised, they don't get clear pin/pass information. Thieves of the server table would need to break the hash, but widely available rainbow tables make that very viable.

Better-Still, is a HASH of the pin/pass + SALT. SALT is a random addition that eliminates the use of pre-computed hash/rainbow tables. Now a table thief has to spend time attempting a brute force attack. Note that with a small pin, this is quite viable as well.

Better-Still-More, is to add "round counts" of hashing the hash of the hash of the hash a few thousand to million times. This requires a thief to know the round count and if the count is large enough to require 2-3 seconds per attempt, brute force becomes even more difficult. Note that a small pin is still vulnerable.

The Bigger Concern and most common mistake made again and again is failure to prevent direct online brute force attacks. People make mistakes and need to be allowed multiple attempts, but a realistic limitation along the lines of say, 5 attempts within a 3 minute window, accounts for humans but hundreds of attempts at impossible typing speeds is an attack, don't allow that! The Linux utility "Fail2Ban" is handy for blocking these kinds of online attacks. Too many attempts within the window, block the IP for 30 minutes. A real person can wait it out to try again, but an automated high speed attack will generally give up and move on.

  • Ok it makes sense but one more thing. I need to first register/sign-up to set the pincode (so I can change it or remove it later on by using my password). That means it has to be related with my account/credentials in the server, right? – zgulser Jan 16 at 23:34
0

There are multiple ways to do this. It will depend on what language/s you are using, what your server/client architecture it, are you limited to un-encrypted transmission protocols, etc.

Here is an almost duplicate question (if you can give us your technology stack it might not be): https://stackoverflow.com/questions/35100181/how-to-make-login-authentication-page-in-html-or-javascript

More Reading: https://sushi2k.gitbooks.io/the-owasp-mobile-security-testing-guide/content/0x04e-Testing-Authentication-and-Session-Management.html

https://techbeacon.com/5-essential-steps-securing-enterprise-mobile-apps

  • Thank you. But I'm not asking for a general idea. I'm looking for how pincodes are used during the authentication as a safe login mechanism. None of those pages referring the pincode usage. – zgulser Jan 15 at 9:23

Your Answer

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

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