我的程序要求用户创建一个 4 位密码（很像 iPhone 内置的解锁屏幕）。该程序将存储密码并根据稍后输入的密码进行测试，并拒绝或允许访问文档的表格视图。我还需要将密码存储在 iCloud 中，以防其他设备想要使用相同的文档数据库。我不需要需要存储用户名信息。
我一直在阅读有关使用钥匙串的信息，但这对于我的目的来说似乎有点矫枉过正。我是安全方面的初学者，不知道该做什么和不该做什么。谁能给我指出正确的方向，让我可以阅读哪些适合我的应用程序的文档或教程？感谢您的帮助。
更新
关于使用钥匙串回复以下答案的注意事项：
如果我要使用钥匙串，我从苹果文档中得到的印象是我无法也不能我应该将密码存储在 iCloud 上吗？这提出了一个有趣的问题，因为在 iCloud 上存储文档是我的应用程序的基本行为，因为用户需要跨多个设备访问受密码保护的同一组文档。我该如何解决这个问题？是否有一种已知的安全方法可以解决此问题，或者我是否必须完全放弃使用钥匙串？
My program asks a user to create a 4-digit passcode (much like the unlock screen built into the iPhone). The program will store the passcode and test it against a passcode entered at a later date and will deny or give access to a tableview of documents. I also need to store the passcode in iCloud incase another device wants to use the same database of documents. I do not need to store username information.
I've been reading about using keychain but this seems like a bit of overkill for my purpose. I'm a beginner to security and have no clue on what to do and what NOT to do. Can anyone point me in the right direction for what documents or tutorials I could read that would be appropriate for my application? Thanks for the help.
UPDATE
note about using keychain in reply to the answers below:
If I was to use keychain I'm under the impression from the apple docs that I would not be able to nor should I store the passcode on iCloud. This presents an interesting problem because storing documents on iCloud is an essential behavior of my application as users need to access the same set of documents which are protected by a passcode across multiple devices. How do I approach this problem? Is there a known secure way to work around this or would I have to totally abandon the use of keychain all-together?
发布评论
评论（2）
您打算进行简单的字符串比较作为假装安全措施，还是实际上加密私有数据并且只是使用故意弱化的密钥？
两种方法都是有效的，但我假设您的用户希望后者。 （它们会是如果有人直接从手机备份转储中以纯文本形式读取他们的数据，会感到不安吗？）
如果您实际上使用故意弱的密钥来加密他们的数据，那么您绝对应该使用内部钥匙串，并可能使用 PBKDF2 来根据您可用的秘密数据量非常少。任何其他方法都可能会让您陷入尴尬的境地或彻底敌对的用户。让苹果尽可能地管理。 （不要将密钥存储在 iCloud 中。）
请注意，使用钥匙串和 PBKDF2仍然会让您的用户数据处于开放状态，很容易被暴力破解密钥猜测，但这必须是预计有这样的快捷键。
Are you intending to do a simple string comparison as a pretend security measure or are you actually encrypting private data and just using a key that's intentionally weak?
Both approaches are valid but I assume your users expect the latter. (Would they be upset if someone read their data in plain text right out of the phone backup dumps?)
If you're actually encrypting their data with an intentionally weak key, then you definitely should use the internal keychain and probably use PBKDF2 to make a useful key based on the very short amount of secret data available to you. Any other approach is probably setting you up for embarrassing situations or outright hostile users. Let Apple manage as much as they can. (Do not store the key in iCloud.)
Note that using keychain and PBKDF2 will still leave your user's data open to pretty easy brute-force key guessing, but that must be expected with such short keys.
我认为 SHA1 适合您的目的
只需记住在原始字符串中添加一些“盐”即可
我2年前在iphone App Obj-C上做过，应该很简单
这篇文章可能有帮助
目标 C：SHA1
:) 希望有帮助
I think SHA1 is good for your purpose
just remember to add some "salt" to your raw string
I did it on iphone App Obj-C 2 years ago, should be straightforward
this post may help
Objective C: SHA1
:) hope it helps