On Wed, Aug 27, 2014 at 1:21 PM, Kapil Gambhir <[email protected]> wrote: > But that is the crux of the issue right, if we prompt a password to retrieve > another password, why store the password at all, why not ask the password > which is being saved itself. > It defeats the purpose of saving the password itself. There's a subtle difference.
To access a website, you'd use a username and password with 12 or 16 characters. You want a long password to make it difficult for the network attacker who tries guessing attacks. 12 to 16 gets cumbersome to type when needed. So you encrypt the big password that's hard to guess for the network attacker, and encrypt it with with a key derived from a shorter password plus salt. The shorter password is easier to remember and type for the user. Also, each site gets its own password, so the single shorter password can protect a collection of longer passwords. Jeff > On Tuesday, August 26, 2014 6:22:35 AM UTC+5:30, Jeffrey Walton wrote: >> >> On Tue, Aug 12, 2014 at 7:28 AM, Kapil Gambhir <[email protected]> >> wrote: >> > What is the recommended approach for an app to securely store the >> > username/password credential on android, so that no one else can sniff >> > that >> > sensitive data. Bigger issue being that most of the users dont use the >> > whole >> > disk encryption. >> > I was playing around with SharedPreferences(seems to be clear text), >> > AccountManager(not encrypted) and KeyChain(not for passwords but keys >> > and >> > certificates) but because of the reason mentioned in braces am not sure >> > of >> > the right approach to store the user credentials so that its security is >> > respected. On the wire, the app would be using SSL, so that part if >> > covered, >> > its largely the on the device storage of secured credentials. >> > >> It can't really. That problem is known as the "unattended key storage" >> problem, and its a wicked hard problem. Gutmann talks about it in his >> book Engineering Security >> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). >> >> Usually, the idea is to prompt the user for some entropy or a secret >> (i.e., a password). Combine it with some additional entropy like a >> salt (a random value stored in Keychain or Keystore). Once combined, >> use the combined value as a key to decrypt other sensitive >> information, like usernames or passwords for a website. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
