I don't have a security background, so I'm not sure on the best approach for this, I'm developing an android app which users will need to login to (all local). I'm going to store the password in a sharedPreference and found this. If I understand it correctly, it doesn't seem to be salting it, so I was thinking about adding a digest.update(byte[]) after the 'MessageDigest digest = MessageDigest.getInstance("SHA-256");' line. Is that a good way to do it? Or should I pass in base + salt to the hash as a parameter?

Also, is a salt + hash safe enough? Or is it better to just use an actual encryption function (the ones I'm looking at right now are bCrypt and pbkdf2)? Open to any recommendations.

  • If you're storing passwords bcrypt is generally the best idea. Most good implementations take care of generating the salt for you. Commented Oct 16, 2015 at 23:23
  • Is there any reason you are not using a tested solution for this, like SQLCipher for Android? Commented Oct 17, 2015 at 0:18
  • Part of it is, I'm still researching db encryption (right now, I'm looking at that and SEE), because I do have a back end db I want to encrypt, but the other part is, since sharedprefs are designed to store one offs, I thought it'd be simpler to just store it in a sharedpref. Is this a bad idea? Even if I am salt+hashing it? Or if I end up using bCrypt or pbkdf2 (which I haven't researched enough to figure out implementation yet)?
    – Spider
    Commented Oct 17, 2015 at 0:27
  • What are you trying to protect with the password if all the data is the user's? Are you trying to make sure the phone owner is the only one who can use the app? Commented Oct 17, 2015 at 0:45
  • Yeah, the whole app is just a password vault/generator (I know it's not original and I'm not trying to get rich off it). I ended up creating it, just because I don't trust any that back it up to a server and I just wasn't sure about the ones that weren't as popular and since my work requires me to have a new pw frequently, I wanted something to generate secure ones and then store them (at least until I got used to it).
    – Spider
    Commented Oct 17, 2015 at 1:06

1 Answer 1


Depends on what you are attempting to protect against.

If the password is validated by code that runs on the app, it is subject to tampering, so no amount of encryption or hashing will protect against the ability to execute the (tampered) code without the password.

If the purpose of the password is simply to provide a modicum of protection against casual misuse (e.g. don't want your wife opening up the app) then local hash + salt is probably OK.

  • So the app is completely local, so all the data the person would have access to would be their data. It is storing passwords, so I do want to be careful, but since I don't have a security background I'm not sure what to look out for. Also, from my list, is any of it a good way to salt+hash?
    – Spider
    Commented Oct 16, 2015 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .