帮助在 iPhone 应用程序上有效地实现钥匙串

发布于 2024-09-24 07:36:25 字数 268 浏览 4 评论 0原文

用户请求“锁定”我的 iPhone 应用程序,这是很有意义的,因为它包含私人信息。我相信数据加密超出了人们对手机的期望,因此我的目标只是防止对应用程序的意外访问。我的计划是使用钥匙串来存储密码,并使用我的应用程序名称作为服务名称。

我担心的是,如果用户丢失/忘记输入的密码,会发生什么情况。我可以通过编程执行某些操作来允许用户重置吗?删除应用程序会删除应用程序的钥匙串吗?

我不想收集用户电子邮件。 (嗯,我愿意,但我不希望这成为理由。)并且不希望用户在丢失密码时被永久锁定在应用程序之外。

Users have requested a "lock" on my iphone app, which makes good sense as it contains private information. I believe encryption of the data goes above and beyond what people expect on a phone, so my goal is simply to prevent unintended access to the app. My plan is to use keychain to store the password using my app name as the ServiceName.

My concern is what happens for users if they lose/forget the password they typed in. Is there something I can do programatically to allow a user reset? Would deleting the app delete the keychain for the app?

I don't want to collect user emails. (Well I do, but I don't want this to be the justification.) And don't want the user to be permanently locked out of the app if they've lost the passsword.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

贪恋 2024-10-01 07:36:25

在 iPhone 上只有一个钥匙串数据库,并且无法添加自定义的、特定于应用程序的钥匙串(而您可以在 Mac 上执行此操作)。默认情况下,您添加到应用程序钥匙串的钥匙串项仅适用于您的应用程序。没有文档(据我所知)说明用户删除应用程序时发生的行为:可能是 iOS 4.1 删除了应用程序钥匙串项目,也可能确实将它们留在了钥匙串中。

根据您存储用户密码的方式,您也许能够检索它。例如,如果您将与您的应用程序相关的标签以及用户密码存储在 kSecAttrApplicationTag 中,那么您可以使用该

OSStatus SecItemCopyMatching (
   CFDictionaryRef query,
   CFTypeRef *result
);

函数在钥匙串中搜索您的确切标签。如果搜索成功,那么您可以使用 kSecValueData 键从返回的字典中检索密码,或者,如果您愿意,您甚至可以使用以下命令更改密码。

OSStatus SecItemUpdate (
   CFDictionaryRef query,
   CFDictionaryRef attributesToUpdate
);

有关其他信息,请参阅 钥匙串参考iOS 钥匙串服务任务文档。

On the iPhone there is just a single keychain database, and there is no possibility to add a custom, application specific, keychain (as you can do on a Mac instead). By default, the keychain items you add to the keychain in your app are only available to your app. There is no documentation (to the best of my knowledge) stating the behavior occurring when the user deletes your app: may be iOS 4.1 deletes the app keychain items, may be it does leave them in the keychain.

Depending on how you stored the user's password, you may be able to retrieve it. For instance, if you stored a tag related to your application along with the user's password in a kSecAttrApplicationTag, then you may search for your exact tag in the keychain using the

OSStatus SecItemCopyMatching (
   CFDictionaryRef query,
   CFTypeRef *result
);

function. If the search is successful, then you may retrieve the password from the returned dictionary using the kSecValueData key or, if you prefer, you can even change it using

OSStatus SecItemUpdate (
   CFDictionaryRef query,
   CFDictionaryRef attributesToUpdate
);

For additional information, see the keychain reference and the Keychain Services Tasks for iOS documentation.

葬心 2024-10-01 07:36:25

这里通常的方法是除了(更短、更快)密码或 PIN 之外,还收集一组安全问题和答案。如果用户忘记了密码,她应该能记住更长、更容易记忆的安全问题的答案。

您可以将两者存储在应用程序的钥匙串中。

The usual approach here is to collect a set of security questions and answers in addition to the (shorter, quicker) password or PIN. If the user forgets her password, she should hopefully remember the answers to her longer, more mnemonic security questions.

You can store both in the app's keychain.

尐籹人 2024-10-01 07:36:25

回想起来,我发现我从未用我的实际实现来更新这个问题。

我的问题的核心是我没有用户的联系信息,并且我不会以任何方式复制他们的数据。也就是说,我通过不启用互联网或电子邮件功能来部分保护他们的数据隐私。

因此,我按照上面的建议使用了 SecItemUpdate,同时还为应用程序编写了默认密码(即没有等效密码)。然后,如果用户丢失密码,他们可以告诉应用程序密码丢失,此时应用程序会将密码重置为默认密码并删除数据库中的所有私人数据。因此,丢失密码是有代价的,但任何人都无法闯入并查看私人数据。

我已经使用这种方法几年了,它似乎让我的用户非常满意。

Looking back, I see I never updated this question with my actual implementation.

The core of my issue was that I do not have contact information for my user and I do not copy their data in any way. That is, I let their data remain private, in part, by enabling no internet or email features.

So, I used SecItemUpdate as suggested above, while also coding in a default password (ie, no password equivalent) for the app. Then if the user loses the password, they can tell the app that the password is lost at which point the app resets the password to the default password and DELETES all private data in the database. So, there is a cost to losing the password, but at no point can someone break in and see the private data.

I've used this method for a couple of years now and it seems to satisfy my users perfectly well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文