views:

42

answers:

1

Are there any known pitfalls to avoid when storing user passwords in the Keychain? I am planning to give users the ability to require a password in order to access my iPad app. I have basic read and write of a string to the Keychain working. I just want to make sure that I don't allow them to get into a scenario that they lock themselves out through no fault of their own. For example:

  • Would the keyboard allow them to enter special characters that couldn't be saved or read from the keychain
  • Is there a limit on the string length

Thanks for any insight you can share.

+1  A: 

Save the password. Read it back. Make sure it works. If not, tell the user that it failed and make them enter a different password.

Not all keyboards can enter all characters. The phone-lock keyboard in 3.1.2 or so (not sure if they've fixed it) had a bug where it would restrict you to "ASCII-capable" keyboards (e.g. not Hebrew), but not restrict the characters that could be entered; enabling certain keyboards would add additional accents, and some keyboards had additional symbols. You could then disable some keyboards, lock the phone, and be completely unable to unlock it. (I made a backup before testing this.)

In your case, you don't stop the user from keyboards, so this is less of an issue.

Note that you're approaching this from the wrong direction: The password unlocks content. You are trying to keep the content secure. You don't need to save the password anywhere (you could just use it to encrypt the content).

Files will also appear unencrypted in (unencrypted) backups. In 3.1.2, you could back up a passcode-locked phone (not sure if they fixed this in 3.2); this meant that on a device with no backup password, you can steal everything by attaching it to a laptop and pressing "Backup".

Effectively implementing crypto yourself is beyond the scope of this answer.

tc.
Encryption may require a filing CCATS document in your particular jurisdiction, which may incur non-zero legal costs. That's a good reason not to use it for apps that aren't meant to really be secure, e.g. for a "kid-sister" password lock on a game character or a hi-score.
hotpaw2
I just dislike the idea of adding more *apparent security* than actual security, but I wouldn't recommend plastering "Note that this isn't 100% secure" everywhere either — it's difficult to communicate "levels" of security to a user and difficult for them to understand it. But if you store users' passwords at all, definitely stick them in the keychain — users reuse passwords.
tc.
Thanks for your reply. Just to clarify, I'm not intending to encrypt the content (e.g. documents in the app), I'm planning to catch the app at launch and require the password to proceed. The problem I'm trying to solve for is: I'm sharing my iPad with other people. I don't want them to see what I'm going in this particular app. I guess I could try encrypting specific files to prevent them from being read after the app launch, but I think that's probably above and beyond what my users require.
DenVog
On the Keyboard topic, I tried so simplify this problem by limiting to the UIKeyboardTypeNumberPad, but iPad does not seem to present this like the iPhone (i.e. just numbers and return). There are still letters and punctuation visible.
DenVog
Your post gave me another idea. Maybe I shouldn't use a UITextField and keyboard at all. Just display a UIPicker view with numbers as a PIN. Perhaps this would be the safest.
DenVog
A picker is much easier for eavesdroppers though. You can filter the text received to ensure that it only contains ASCII characters, though.
tc.