管理必须存储在 sqlite iPhone 应用程序上的密码的最佳方法

发布于 2024-11-29 15:52:31 字数 222 浏览 3 评论 0原文

我有一个 iPhone 应用程序,必须离线工作,并且需要能够供使用同一设备的多个用户使用。

我现在将通行证存储在 sqlite 数据库中。它必须在那里...因为该数据库与普通 SQL Server 框中的另一个数据库同步。

所以,我读了员工的用户名和信息。来自主数据库的密码并将该信息发送回 iPhone bd。当用户登录时,应用程序从本地 bd 读取。用户离线工作,然后最终再次与主 bd 同步。

I have a iPhone app that must work offline, and need be able to be used for several users with the same device.

I store now the pass inside the sqlite database. It must be there... because the database is in sync with another one in a normal sql server box.

So, I read the staff usernames & password from the master db and send back that info to the iPhone bd. When a user login into it the app read from the local bd. The user work offline then eventually sync again against the master bd.

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

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

发布评论

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

评论(1

不知所踪 2024-12-06 15:52:31

我不太确定您的问题是什么......

如果是“如何防止人们窃取设备上存储的数据”,那么答案是您不能。如果它存储在设备上,那么任何具有直接物理访问权限的人都可以提取任何存储的秘密。

特别是如果您的代码位于设备上,那么黑客可以从中提取任何加密密钥或其他嵌入式资源(包括数据库)。

所以,如果你想阻止这种情况发生,你就知道你做不到。如果材料具有足够敏感的性质,那么我会说完全放弃“断开连接”的模型。

如果它不是那么敏感,并且您只是想阻止某人闲逛,那么只需执行我们通常所做的操作即可:加密数据库并将密钥存储在您的应用程序中。


更进一步,如果您想防止被盗的手机被盗,那么您唯一的选择就是启用远程擦除。然而,即使这样也只能在手机丢失后迅速报告且偷手机者不知道如何拔出 SIM 卡来阻止手机丢失的情况下才能挽救您的生命。


归根结底,黑莓在安全性方面仍然击败了苹果。


更新:我的评论太长了。

@mamcx:我认为您不太了解问题的范围。设备上的任何数据都可能受到损害,包括存储在钥匙串中的密码。在 iPhone 上,这其实并不难。

假设您使用盐对密码进行哈希处理并将其存储在本地 sqllite 数据库中。现在,当断开连接的用户输入他们的用户名和密码时,您的代码将必须对他们输入的内容进行哈希处理,添加盐并将其与本地数据库中的值进行比较。

由于设备的断开连接特性,执行此操作所需的所有信息都存储在设备上。这包括哈希算法和盐。

现在,假设设备被盗或者内部员工决定戴黑帽子。提取所有数据很简单。这可以以非破坏性的方式完成,并且设备可以被放回原处,而没有人知道它丢失了。此时黑客只要创建彩虹表就可以破解密码了。哎呀,有些“公司”会在各种云上租用时间来为您构建彩虹表

当然,密码本身并不是那么必要,除非黑客想要转售它们,因为您的所有数据都已经丢失。

那么,问题是:数据有多重要?如果您不能丢失它,请不要允许应用程序在断开连接的情况下运行。如果不是那么重要,那么一定要在本地进行。只是让用户知道他们不应该使用他们在其他地方使用的用户名/密码。

I'm not exactly sure what your question is...

If it's "how can I keep people from stealing data stored on a device" then the answer is You can't. If it is stored on a device then anyone with direct physical access can pull any stored secrets.

In particular if your code is on the device, then a hacker can pull any encryption keys or other embedded resources (including database) off of it.

So, if you're trying to prevent that just know that you can't. If the material is of a sensitive enough nature then I'd say abandon the "disconnected" model entirely.

If it isn't that sensitive and you are just trying to keep the someone from poking around then just do what we normally do: encrypt the database and store the key in your app.


Going a little bit further, if you are trying to prevent a stolen phone from being compromised then you're only choice is to have remote wipe enabled. However, even that can only save you if the lost phone is reported quickly AND the person who stole it doesn't know how to yank the SIM card to stop it.


At the end of the day, blackberry still blows apple away in security.


UPDATE: my comment was going to be too long.

@mamcx: I don't think you're quite understanding the scope of the problem you have. ANY data on the device can be compromised, including passwords stored in the keychain. It's really not that hard on the iPhone.

Let's say you hash the password with a salt and store that in your local sqllite db. Now, when a disconnected user types in their username and password your code will have to hash what they typed add the salt and compare it against a value in the local db.

ALL of the information necessary to do this is stored on the device due to the disconnected nature of it. This includes the hashing algorithm and the salt.

Now, let's say the device is stolen OR an internal employee decides to wear a black hat. Pulling all of the data is simple. This can be done in a non destructive way and the device could be put back without anyone knowing it was missing. At this point the hacker has as long as they want to create the rainbow tables to crack the passwords. Heck, there are "companies" that will rent time on various clouds to build the rainbow tables for you.

Of course, the passwords themselves aren't that necessary, unless the hacker wants to resell them, because all of your data is already lost.

So, the question is: how important is the data? If you can't lose it, don't do allow the app to run disconnected. If it's not that important, then by all means do it locally. Just let the users know that they shouldn't use a username / password they are using elsewhere.

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