[Pharo-dev] Recommendation for password encryption?

On Jul 15, 2013, at 10:42 , Mariano Martinez Peck wrote:

> Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key?
> or it make sense to put a "salt" together with the string to ecnrypt?
>
> Thanks

No. Salts (and one-way hashed passwords) only make sense when you're the one authenticating login credentials, not when you're the one tasked with providing said credentials.

There is *no* good way of securely "remembering" passwords for a client, other than (as Norbert said) restricting access to the place the password is stored using permissions.
As such, you could just as well store the password in-image, and keep it in a restricted location/run as separate user with access to that location.

Keeping a blowfish key in a separate file, used to decrypt some in-image value to get the actual password, only buys you safety against
1. Someone gaining access to the image, but not the file
2. Reading cleartext passwords from the process memory directly.

For 1), it should be obvious that it is mostly a moot point, if you place the image in a similarly restricted location anyways.
For 2), I *think*, no modern OS lets you read another users process' memory (on purpose *) unless they have root access/logged in as same user, in which case, well, you're already screwed.
Sure, there might be exploitable bugs that lets an attacker read memory of other processes, but such usually have a high fix-priority.
It also means, in order to never end up keeping the plaintext password in memory for prolonged durations (and vulnerable to being read), you have to re-read the file every time you provide the password, so the image must be run as a user with access to the files location anyways.

A usable alternative exists if you already use client-side credentials for your app, provided manually when a user signs in.
Then, in addition to salt + hashed password value for your users, you can store the db-passwords encrypted with a symmetric cipher (like blowfish) using the users password as key.
At login time, after authenticating, you then also decrypt the db-passwords, and keep them available while the application runs.
This of course, is still vulnerable to potential memory dumps, but you never store the passwords in an easily reversible form if an attacker ever gains access to the files.

If introduced to an existing application , it also means you'd have to keep the db-passwords around in plantext for awhile, to create encrypted values for users on first login (if non-existing), after that passwords should already be available in memory for calculation of new encrypted values when changing passwords/ adding new users. (due to those being allowed to do so, being logged in already)

If it's a non-deployed app, the encrypted value for some super-user can be calculated before deployment, and the data required to decrypt the db-passwords never kept on disk in production.

Cheers,
Henry