Question

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.

Here is what I am trying to figure out:

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?

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) 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.

Answer 1

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?

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.

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)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.

友情链接