Yes, it is typical to have a PIN to protect the longer password on device,
but as I user it is probably still annoying.
You could also use the AndroidKeyStore's ability to have a public/private
key pair to build something else. you could use the public key pair to
protect a symmetric key, storing that encrypted on the disk. you can use
the private key held in the AndroidKeyStore to decrypt the symetric key
when needed. You then use the symmetric key to protect a password file.
See discussion here:
https://groups.google.com/forum/#!topic/android-developers/gbmIRKRbfq8
and code sample here:
https://android.googlesource.com/platform/development/+/master/samples/Vault/src/com/example/android/vault/SecretKeyWrapper.java
though I haven't vetted the code.
But it depends what attack you are trying to prevent. as far as "no one
else can sniff that sensitive data", this might prevent someone from
removing the flash memory from the device and reading a plain text
password. it also prevents attacks by "adb backup/restore". but if another
app can break into your process, they can probably access they key store as
you as well, so its the same as storing it in plaintext on disk.
-bri
On Wed, Aug 27, 2014 at 5:19 PM, Jeffrey Walton <[email protected]> wrote:
> 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.
>
--
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.
