2

Overview is we encrypt the credentials using the pincode as the passphrase that the user also sets. One of the requirements is to NEVER SAVE THE PINCODE anytime anywhere.

Everytime the user goes out of the app or exits the app, a lock screen will show when the user runs the app again that asks for the user's pin code. The app will then try to decrypt the credential using the pin code that the user entered.

Now if the decryption is successful, we put the credential in a variable on our singleton because we need the credential for various things like regeneration of session with the server and as passphrase for encrypting downloaded files.

I would like to ask if it is safe to do this, because from my research, this is how web developers do it but websites have servers that are secured inside of a company unlike an iOS device that anyone can have their hands on.

4
  • Is the decrypted credential removed from memory when the application exits or is switched away from? Does the app run on rooted devices? If it is in memory at any point, a determined attacker can get it, but it is very difficult to work without anything in memory!
    – Matthew
    Feb 5, 2016 at 12:11
  • The memory allocated to the app is wiped out when the app exits, but not when if you just pressed the home button, which just puts the app in background. And yes it's practically impossible for us to do other things we need with the credential if it's not stored in a variable. But you gave me an idea that I need to wipe the memory even when it goes to background, this adds an additional security
    – Bryan P
    Feb 5, 2016 at 12:14
  • What is your threat model?
    – Lie Ryan
    Feb 6, 2016 at 10:01
  • I tried doing some short research about threat models but It's complicated, can't learn it as I need to do the codes, sorry @Lie Ryan, can't answer your question.
    – Bryan P
    Feb 7, 2016 at 7:44

1 Answer 1

1

Are you defending against an attacker with full access to the device? If so, a credential encrypted with a PIN code (which implies it consists of only 4 or 6 digits) is very easy to decrypt - a maximum of only 10,000 or 1,000,000 tries and you're there.

I would recommend verifying the PIN that the user entered against the server for authentication, and limiting (server-side) the amount of tries the user is allowed.

4
  • Yes, we are trying to prevent an attacker from knowing the credentials and the downloaded files of the user. Unfortunately, we are (outsourced) in a situation where the server (client's) can't be modified. So we can only improve the app's security.
    – Bryan P
    Feb 7, 2016 at 7:41
  • 1
    In that case I think your only option is to increase the complexity of the PIN, and to increase the complexity of the hashing algorithm so that verifying it takes a long time per try
    – Mark Koek
    Feb 12, 2016 at 14:03
  • Is it really easy? The FBI did struggle with this after all. The whole disk encryption present on all devices beyond iOS 4 ensures the disks data cannot be copied, the device itself adds a delay between incorrect attempts and wipes the user's data should there be more than ten incorrect attempts. With older devices we need to ensure these things are set though. Apr 19, 2016 at 8:50
  • This is why I asked if the attacker has access to the device. Getting access to the device is a different question entirely. Although apparently, the FBI can now do it. :)
    – Mark Koek
    Apr 19, 2016 at 9:36

You must log in to answer this question.

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