应用程序密码和SQLite安全性 [英] Application passwords and SQLite security

问题描述

我一直在google上搜索关于应用程序密码和SQLite安全性的信息一段时间，没有找到任何东西真的回答了我的问题。

I have been searching on google for information regarding application passwords and SQLite security for some time, and nothing that I have found has really answered my questions.

这里是我试图找出：

1）我的应用程序将有一个可选的密码活动，当应用程序首次打开时将被调用。我的问题是这样的）如果我存储密码通过Android首选项或SQLite数据库，我如何可以确保安全和隐私的密码，和b）应该如何处理密码恢复？

1) My application is going to have an optional password activity that will be called when the application is first opened. My questions for this are a) If I store the password via android preference or SQLite database, how can I ensure security and privacy for the password, and b) how should password recovery be handled?

关于b）从上面，我已经考虑要求在启用密码功能时要求一个电子邮件地址，以及一个密码提示问题，在请求密码恢复时使用。在成功回答提示问题后，密码将通过电子邮件发送到提交的电子邮件地址。我不完全相信电子邮件方法的安全性和隐私性，特别是当用户连接到开放的公共无线网络时发送电子邮件。

Regarding b) from above, I have thought about requiring an email address when the password feature is enabled, and also a password hint question for use when requesting password recovery. Upon successfully answering the hint question, the password is then emailed to the email address that was submitted. I am not completely confident in the security and privacy of the email method, especially if the email is sent when the user is connected to an open, public wireless network.

2 ）我的应用程序将使用一个SQLite数据库，如果用户有一个存储在SD卡上。无论它是存储在手机还是SD卡上，我对数据加密有什么选择，以及如何影响应用程序的性能？

2) My application will be using an SQLite database, which will be stored on the SD card if the user has one. Regardless of whether it is stored on the phone or the SD card, what options do I have for data encryption, and how does that affect the application performance?

提前感谢花费时间回答这些问题。

Thanks in advance for time taken to answer these questions. I think that there may be other developers struggling with the same concerns.

推荐答案

1）密码恢复很危险。密码的强度被一个问题的答案所破坏，这是最薄弱环节的原理。 Sara Palin的电子邮件黑客可能是因为这个（非常）不安全的特征。此外，如果您将密码存储在可恢复格式中，如像AES的块密码或像RC4的流密码或像RSA的非对称密码，那么您明显违反了 CWE-257 。如果您确实需要此功能，您必须要求用户重置他们的密码，如果他们不知道，那么您为什么需要告诉他们？

1) Password recovery is dangerous. The strength of the password is undermined by the answer to a question, this is the principal of the weakest link. Sara Palin's email hack was made possible because of this (very) insecure feature. Also if you store the password in a "recoverable format" as in a block cipher like AES or stream cipher like RC4 or an asymmetric cipher like RSA then you are in clear violation of CWE-257. If you really need this feature, you must require that the user reset their password, if they don't know it, then why would you need tell them?

密码必须始终使用安全的消息摘要进行散列。目前许多消息摘要函数是不安全的，md4，md5，sha0和sha1都非常破坏，不应该用于密码。目前sha2系列的任何成员都是最好使用的功能，我推荐SHA-256。 NIST目前正在为sha3举办比赛，并且将在2012年某个时间之前完成。

Passwords must always be hashed using a secure message digest. Currently many message digest functions are insecure, md4, md5, sha0 and sha1 are all very broken and should never be used for passwords. Currently any member of the sha2 family is the best function to use, I recommend SHA-256. NIST is currently holding a contest for sha3 and it won't be finalized until sometime in 2012.

密码也必须以大的随机值salted。这可能是数据库中的另一列，然后在将其传递到消息摘要函数之前附加到纯文本密码。这使得字典攻击不可能除非攻击者可以获得盐，它也使预先计算的攻击远远更资源密集成功地进行。尽管知名度很高，但盐析不会停止彩虹表，这意味着您需要大多数彩虹表。

Passwords must also be "salted" with a large random value. This could be another column in your database which is then appended to the plain text password before passing it to your message digest function. This makes dictionary attacks impossible unless the attacker can obtain the salt, it also makes pre-computed attacks far more resource intensive to conduct successfully. Despite popular knowledge, salting does not stop rainbow tables, it just means you need a MUCH LARGER set of rainbow tables.

2）您要将加密数据库的密钥放在哪里？ Sqlite只是一个文件，你可以加密这个，然后解密它，当你的应用程序启动，这只是增加了一些加载时间，但在运行时，它将是一样快。真正的问题是有绝对没有地方你可以在设备上放置一个攻击者无法获得的秘密。与攻击者相比，攻击者可以对设备进行更多的控制，攻击者可以越狱并做任何想要的操作。即使密钥在运行时传输，仍然可以通过查看设备的内存来获得。任何加密数据库的努力都可能被破坏，它可以使它更困难，但它不会停止一个熟练的黑客。

2)Where are you going to put the key for your encrypted database? Sqlite is just a file you could encrypt this and then decrypt it when you app starts up, this just adds some load time but at runtime it will be just as fast. The real problem is there there is absolutely no place you can put a secret on the device that an attacker cannot obtain. An attacker has more control over the device than you do, an attacker can jailbreak the device and do whatever they want. Even if the key is transfered at runtime it can still be obtained by looking at the device's memory. Any efforts to encrypt the database can be undermined, it can make it more difficult but it won't stop a skilled hacker.

这篇关于应用程序密码和SQLite安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！