My recruitment app is licenced by the number of users and the encryption password is part of an encrypted (with another unique password embedded in the app) licence file I create for each installation. I'm starting on a new app which will not have a licence for the number of users but I want to give the users the option of creating an encryption password themselves. The intention is to make it multi-user both f/s & c/s.

My recruitment app is very low volume so doing it the way I do is easy.

Part of the data in this new one will be peoples info which is why I want to encrypt it. Any suggestions as to how to let people set their own encryption password without them having to enter it on startup and being stored in a simple file?

Roy Lambert

Roy,

It would be (in theory) vulnerable sine you're storing the password. Saving just a userid+password hash and having users enter it each time so you can validate the hash would be most preferable though PITA for users.

My suggestion would be something like this:
1. use a separate encrypted table for storing usernames/passwords (that only your app knows encryption password for)
2. store the userid and encrypted copy of the password in there (using a symmetric encryption method for password).
3. use userid+fixed string (or similar) as the actual password for encrypting the user password to prevent copying the password fields from one row to another
4. store a hash of the record (computed from userid+encrypted password+some fixed strings) to be able to validate that username/password fields have not been changed in the table

Raul

Raul

>It would be (in theory) vulnerable sine you're storing the password. Saving just a userid+password hash and having users enter it each time so you can validate the hash would be most preferable though PITA for users.

It will definitely be vulnerable, all I'm looking for is to reduce the vulnerability to an acceptable level for the type of app.

>My suggestion would be something like this:
>1. use a separate encrypted table for storing usernames/passwords (that only your app knows encryption password for)
>2. store the userid and encrypted copy of the password in there (using a symmetric encryption method for password).
>3. use userid+fixed string (or similar) as the actual password for encrypting the user password to prevent copying the password fields from one row to another
>4. store a hash of the record (computed from userid+encrypted password+some fixed strings) to be able to validate that username/password fields have not been changed in the table

Similar to what I'm doing with the external licence file but the idea of a separate session/database/table to store the password has given me a few thoughts - thanks.

Roy Lambert