1

I'm a complete novice at this and in need of advice. I'm building an app that I've implemented a password encrypted backup feature into. I'm wondering about the best practice for handling the salt. With a centralised database I know that it's essential to have a random salt as a defence against hackers, but what about when there is no centralised database for a hacker to attack? Is it acceptable to hard code a salt into my app, or should it be randomly generated and then hardcoded into the outputted encrypted file?

Any advice much appreciated.

vquest
  • 21
  • 2
  • 1
    if it is hardcoded into the app, anyone with the app can start attacking the passwords of anyone else with the app, well in advance of getting access to their device or backup file – Richie Frame Sep 20 '20 at 02:14
  • 1
    also see https://crypto.stackexchange.com/questions/18963/should-you-change-salt-when-changing-password – Richie Frame Sep 20 '20 at 02:29
  • I'm not sure how they could do it without having possession of the encrypted file, since it is the encrypted file that contains the backup data. I'd have thought that they'd need physical possession of the file itself? – vquest Sep 20 '20 at 02:33
  • 1
    if the salt and algorithm are hardcoded into the app, they do not need the file to start working on a password list, but they will need it for verification and decryption – Richie Frame Sep 21 '20 at 07:56
  • Thanks. Both your and Meir's reply has helped me to clarify it. I'll definitely go with a unique salt for each file, which leads me to my next investigation. How to go about embedding it. – vquest Sep 22 '20 at 06:09
  • since you need to read the salt encrypted key in order to decrypt the file, just prepend or append to the file in a fixed length field with its own unique prefix and suffix, such as "$$VQ01P$alg$cost=xx$encoded_salt$encoded_key$encoded_nonce$encoded_tag$VQ01S$$". Appending to the data (or storing in another file) means you can encrypt the file "in place" which is sometimes useful, and encrypting the encryption key with the password means you can change the password without reencrypting all your files – Richie Frame Sep 23 '20 at 00:04
  • Thanks for that, Richie. I'm not quite sure what I'm looking at with the salt that you posted, but I get the prefix and suffix. I am planning on simply generating a unique sequence of letters and numbers for the salt, which from what I've researched so far seems to be an okay approach. – vquest Sep 25 '20 at 05:18
  • I think stack exchange formatted it weird, it is just a string of a file footer with some variables and the dollar sign for separation like the modular crypt format uses, the format helps you find it at the end of the file, and then parse it to extract the salt, nonce, key, and auth tag so you can decrypt, I will see if it looks better if I delete and repost – Richie Frame Sep 25 '20 at 10:25
  • %%VQ01P%alg%cost=xx%encoded_salt%encoded_key%encoded_nonce5encoded_tag%VQ01S%% – Richie Frame Sep 25 '20 at 10:25
  • Ahh, okay. That makes sense. I'll only need to extract the salt when restoring the file, so that's pretty easy. I'm using common crypto with a wrapper that a moderator gave me over at the Apple Developer forums. – vquest Sep 26 '20 at 02:20

1 Answers1

3

The salt should be different for each user. It is therefor far more secure to attach the salt to the encrypted file than to have a fixed "salt". A fixed vale for the entire system, often called a "pepper" will still allow attacking multiple accounts together. To ensure you can't attack multiple accounts together use a different salt for each. If you don't have a DB, prepending the salt to the encrypted file next to an IV/nonce is reasonable.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54
  • 1
    You might even be able to merge nonce with salt and save a few bits, but would be simpler not to and you don't really need those bits. – Meir Maor Sep 20 '20 at 05:53
  • Thanks for that. I should flesh out the context a bit more. There are no accounts or stored passwords. The data is local to the users device. They back it up to a password encrypted file, which they'll save to a place of their choice. Given that a would be attacker must steal the file first in order to attack it, embedding it in the file hands him the salt. He can't attack multiple people unless he steals from multiple people. Still, I guess a single salt would still make it easier, in that a lot can be prepared before any thieving begins. – vquest Sep 20 '20 at 06:59