钥匙串密码陷阱
在钥匙串中存储用户密码时是否有任何已知的陷阱需要避免？我计划让用户能够需要密码才能访问我的 iPad 应用程序。我可以对钥匙串进行基本的读写操作。我只是想确保我不会让他们陷入这样的情况：他们因为自己的过错而将自己锁在门外。例如：
- 键盘是否允许他们输入无法保存或从钥匙串读取的特殊字符？
- 字符串长度是否有限制？
感谢您分享的任何见解。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
保存密码。读回来。确保它有效。如果没有，请告诉用户失败并让他们输入不同的密码。
并非所有键盘都可以输入所有字符。 3.1.2 左右的手机锁键盘（不确定他们是否已修复）有一个错误，它将限制您使用“支持 ASCII 的”键盘（例如，不是希伯来语），但不限制可能的字符进入；启用某些键盘会添加额外的重音符号，并且某些键盘具有额外的符号。然后，您可以禁用某些键盘，锁定手机，并且完全无法解锁它。 （我在测试之前做了备份。）
在您的情况下，您不会阻止用户使用键盘，因此这不是什么问题。
请注意，您的处理方向是错误的：密码解锁内容。您正在努力确保内容的安全。您不需要在任何地方保存密码（您可以仅使用它来加密内容）。
文件在（未加密）备份中也将显示为未加密。在 3.1.2 中，您可以备份密码锁定的手机（不确定他们是否在 3.2 中修复了此问题）；这意味着在没有备份密码的设备上，您可以通过将其连接到笔记本电脑并按“备份”来窃取所有内容。
自己有效地实施加密超出了本答案的范围。
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.
关于字符串长度：
iOS 钥匙串上的最大可存储字符串长度和字符串的最大可能长度没有区别。然而，人类可能不会生成那么长的字符串，更不用说记住它了。
值得一提的是，存储到钥匙串的大值会对性能造成影响，因为必须对其进行加密/解密才能写入和读取。
相关文章：
解码一个巨大的 NSString，内存不足
NSString stringWithFormat 很慢
Regarding String length:
There is no difference between the maximum storable string length on the iOS Keychain and the maximum possible length of a string. A human is likely not going to generate a string that long though, let alone remember it.
It's pertinent to mention that there is a performance hit for large values being stored to the keychain, since it has to be encrypted/decrypted to be written and read.
Related posts:
decoding a HUGE NSString, running out of memory
NSString stringWithFormat is slow