0

I've recently learnt that to store a password securely you should use slow cryptographic hash functions with salt and store the hashed password and salt in some server.

But how should I store a password securely for an offline application? I'm afraid that if someone got a hold of the users phone, they could root the phone to get the files where all the sensitive information is stored and get either the hash, salt used for hashing or just replace the hashed password with their own hashed password. Are there any tricks that I can deploy to make my offline app's password more securely stored?

Edit: Just to clarify, I'm more interested in protecting the users password than the entry through to the app.

AMVaddictionist
  • 116
  • 1
  • 13
  • Hash a password and store it in your sqlite dB and everything is fine. Even if someone gets hold of the hashed password it would be useless for them and if they temper with it then they won't be able to use the passwd in your app – Arpit Solanki Jun 22 '17 at 18:09
  • Just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use a function such as `PBKDF2`, `Rfc2898DeriveBytes`, `password_hash`, `Bcrypt` or similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force. – zaph Jun 22 '17 at 19:05
  • @zaph Yeah, that's what I meant by slow cryptographic hash functions. I'm worried that if they get the salt (since I have to store it in the phone) they might just use a dictionary attack with the salt appended to get the password in a reasonable timespan, or is this a non-issue? – AMVaddictionist Jun 22 '17 at 21:33
  • @zaph Also, since I have to store the hash somewhere on the phone, if the attacker finds it, is it possible for the attacker to change the password by changing the hash where it's stored? They won't get the password like this but it seems like an easy way to get past the lockscreen... Assuming it's possible. – AMVaddictionist Jun 22 '17 at 21:41
  • By "get past the lockscreen" do you mean your app for the iPhone lockscreen? Is the attacker the iPhone owner or someone else? Are you concerned about jailbroken iPhones? You need to define the threat model. – zaph Jun 23 '17 at 00:05
  • @zaph By "get past the lockscreen" I'm talking about getting through my Android app's password screen. The attacker is someone else that got a hold of the users Android. I'm concerned about rooted Android devices getting hold of the files where I store the hash and salt and then either use that information to get the users password or entry into my password protected app. – AMVaddictionist Jun 23 '17 at 06:04
  • 1. The salt is not a secret. 2. No security is 100% secure. 3. You need to clearly define what you are protecting, where it exists at rest, how it is transmitted, it's value to you, your users and attackers. Who the attackers might be from the curious to well funded governments. IOW the threat model. 4. If you want more help you will need to provide more information on what you are trying to accomplish. – zaph Jun 23 '17 at 14:17

1 Answers1

0

The hashed password is normally stored on the server because that's where the plaintext password is hashed and compared to the stored hash. You don't transmit the hashed password.

If you're concerned about protecting data on the phone, you don't need to store the password anywhere in any form. Generate an encryption key using the password as a seed. Whenever the user wants to access the data, have them input the password and use the same algorithm to regenerate the key.

Kevin Krumwiede
  • 9,868
  • 4
  • 34
  • 82
  • But I still have to store the generated encryption key somewhere in the phone right? So I can compare the regenerated key with the one generated first. Is this really any safer than storing a hash then? Assuming I understood you correctly. – AMVaddictionist Jun 22 '17 at 18:26
  • @AMVaddictionist You don't need to compare the password or the encryption key generated from it to anything. Simply attempt to decrypt your data. You'll know the password was correct if the decryption works, i.e., if the decrypted data is in the format you expect. – Kevin Krumwiede Jun 22 '17 at 18:53
  • I don't understand, what am I supposed to decrypt? I don't think you mean that I should decrypt the encryption key. Are you saying that I should generate a key and then use that key to encrypt the password? Should I then store this encrypted value somewhere, if not what should I do with it? And so when a user enters a password a new key is generated, if I then decrypt the stored encrypted value with the newly generated key and get the right password I should allow entry? – AMVaddictionist Jun 22 '17 at 20:31
  • @AMVaddictionist You asked about protecting "the files where all the sensitive information is stored." Encrypt those. If the user enters the correct password, they'll be able to decrypt them. If they enter the wrong password, they'll only see garbage. – Kevin Krumwiede Jun 22 '17 at 20:44
  • I'm asking how to store a password securely for an offline app. Even if the app is compromised I want to make it hard enough for the hacker to not bother getting the users **password**. – AMVaddictionist Jun 22 '17 at 21:32
  • @AMVaddictionist Then I don't understand what you're trying to do. What does the password give the user access to, if not sensitive data? – Kevin Krumwiede Jun 22 '17 at 22:00
  • I want to protect the password in case the user reuses their password for other things. If the attacker gets the users password from my app they might have also gotten a free ticket to the users e-mail etc. You could argue that that would be the users issue for not using a unique password, but I don't want to think like that. – AMVaddictionist Jun 22 '17 at 22:12
  • @AMVaddictionist But why do you need the password in the first place? What does it protect? A password that only protects itself is completely pointless. – Kevin Krumwiede Jun 22 '17 at 22:14
  • I want to make a private image gallery app where users can hide images from prying eyes by encrypting images and then decrypt them when logged in, as you have suggested. BUT, I obviously can't protect the images as good as I can protect the password, since that will make the images load too slow. But having your private pictures compromised is not as dangerous as having your actual password compromised and so I want to employ tighter security for that. I wondered if slow hashing the password with salt truly helped considering that the hash and salt is completely visible for anyone trying. – AMVaddictionist Jun 22 '17 at 22:34
  • @AMVaddictionist "having your private pictures compromised is not as dangerous as having your actual password compromised" - I doubt that very much. – Kevin Krumwiede Jun 22 '17 at 22:36
  • 1
    Well, private pictures can't be used to get access to your email while passwords potentially can. But this has gone way off-topic now. – AMVaddictionist Jun 22 '17 at 22:52