1
$\begingroup$

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.

Improve this question
$\endgroup$
10
  • 1
    $\begingroup$ 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 $\endgroup$
    – Richie Frame
    Sep 20, 2020 at 2:14
  • 1
    $\begingroup$ also see crypto.stackexchange.com/questions/18963/… $\endgroup$
    – Richie Frame
    Sep 20, 2020 at 2:29
  • $\begingroup$ 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? $\endgroup$
    – vquest
    Sep 20, 2020 at 2:33
  • 1
    $\begingroup$ 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 $\endgroup$
    – Richie Frame
    Sep 21, 2020 at 7:56
  • $\begingroup$ 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. $\endgroup$
    – vquest
    Sep 22, 2020 at 6:09

1 Answer 1

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ 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. $\endgroup$
    – Meir Maor
    Sep 20, 2020 at 5:53
  • $\begingroup$ 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. $\endgroup$
    – vquest
    Sep 20, 2020 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.