3

I've been doing some research on password hashing/salting. It is my understanding that the salt doesn't need to be secret. But I haven't read anything about the hash itself needing to be secret.

How obscured does the actual hash need to be?

Say I have this simple database table:

User
- username
- salt
- hash

Scenario
I have an online database, well secured/hidden. I can store the salt and hash without any additional encryption, etc... But what if certain users of this database are stored in a local Android SQLite database for offline access. The table looks the same, but now the salt and hash are only protected by a non rooted device (https://stackoverflow.com/questions/3140230/sqlite-database-security). The actual SQLite database can be read easily if someone made a copy of the hidden file. Is it still safe to store the user's salt/hash in this SQLite database as is (each user has a different salt)?

Community
  • 1
Programmer001
  • 133
  • 4
  • 1
    The hash hides the password, which is what you're interested in protecting – Mr. E Jul 25 '16 at 19:49
  • Right. But if the salt and hash were obtained together, the real password still couldn't be derived? – Programmer001 Jul 25 '16 at 19:55
  • If the hash and the salt were obtained togethor, it just becomes a matter of time until the password is gotten. All you have to do is confirm the hash with different passwords over, and over, and over again until you find the right one to generate that hash. Bingo, you have the password. – Robert Mennell Jul 25 '16 at 20:03
  • It gets worse if a flaw is found in the hashing algorithm that allows collisions, because then you just need to get a password that works, it doesn't even need to be the same password. – Robert Mennell Jul 25 '16 at 20:03
  • are you asking if a voluntary user DB breach is ok? (it's not) – dandavis Jul 25 '16 at 20:04
  • More like someone gets access to someone's rooted phone and copies the SQLite database file which has the user's salt and hash. – Programmer001 Jul 25 '16 at 20:05
  • So really what you're more worried about is an attack that causes a Database Dump? – Robert Mennell Jul 25 '16 at 20:13

2 Answers2

2

George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data?

  • Local: A person with physical access to that device. With physical access to the device they can wait to watch the memory for any sort of encryption to be loaded into memory and pull the hash that way. In that case they have the hash. That's one of the issues with physical device access.

  • Remote data exploit: If all they have is a copy of the file that contains the hash(possibly through a DB dump), as long as it's encrypted well on top of hashed it will be a long time before they can decrypt the hash and start trying to get the password out of that hash.

There should be several ways to do this. Choose the one that best fits whatever attack scenarios you're worried about and good luck keeping it(the encryption secret(s) and the hash) safe.

Community
  • 1
Robert Mennell
  • 6,978
  • 1
  • 14
  • 38
  • 1
    Great points. It may be the case that the local SQLite DB should be encrypted, which would include the hash. I'm trying not to overkill this, but we are talking about passwords. – Programmer001 Jul 25 '16 at 20:18
  • Any PII information(which includes passwords and anything else not publicly available) should always be stored securely(encrypted, hashed, etc.) depending on the use case. – Robert Mennell Jul 25 '16 at 20:19
  • 1
    Also if you find an answer useful, even if it's not the answer that was chosen, but just contains useful information, voting it up helps keep it relevant as new answers come in over time. So upvote anything you find helpful! It'll help other people find it useful as well. – Robert Mennell Jul 25 '16 at 20:20
1

I will assume you are using a Strong (slow) Password Hash such as BCrypt with a sufficiently high Work Factor. If you are using a general purpose (fast) hash then the security benefit is very thin.

In most cases the Hash should be kept secret.

  • There may be a vulnerability discovered some time in the future.
  • The hash is a multiplier of password strength. If the password is weak, the resulting hash will be easily cracked soon after the hash value is stolen.

However, if you have sufficiently well-orchestrated Password Strength Requirements, there are some cases where it makes sense to store a password locally.

For example Google's Chromebook uses this technique, allowing a user to use the same password to unlock a Chromebook as the online Google Account.

It would be more secure, however, to use a separate password for this purpose. This way if the mobile device password is compromised the online account is still safe, and vice-versa.

For Chromebooks, Google must have decided that the security-vs-convenience ratio was acceptable for their audience.

If you decide to store the hash on a mobile Android device, then you should go ahead and start a new question to make sure you store it in the most secure location available. Android has multiple possible storage locations and app security settings available.

And most importantly, store as few hashes as possible on the mobile device. Preferably you should only store the one hash that corresponds to the device owner's password.

700 Software
  • 13,897
  • 3
  • 53
  • 82
  • Thanks. I'm planning on using PBKDF2. I might just have to ask a new question regarding storing the hash on an Android device. I'll do a little research first. The main options I currently know of are SharedPreferences and SQLite which both have similar issues with rooted devices. – Programmer001 Jul 25 '16 at 20:08
  • It is likely that both storage methods you mentioned already store the data in the app-private area of the device. (not available to other apps) In your `AndroidManifest.xml` you can mark that the data should not be backed up, neither can it be moved to the SD card. This helps a lot with your security. However, rooted or not, it is best to assume that any of the data could be accessed if the perpetrator has the device in his possession. – 700 Software Jul 25 '16 at 20:39
  • 1
    You can look at Trusted Execution Environment (TEE) and/or Secure Element (SE). See [Android Keystore System](https://developer.android.com/training/articles/keystore.html) as a way to encrypt the hash values in a non-portable fashion, however I would think that one could still alter your app to bypass whatever values it can provide. Maybe it can be used to hash instead of encrypt... Unfortunately no good answers come to mind right now. – 700 Software Jul 25 '16 at 20:43