views:

817

answers:

5

In my last question "Portable database for storing secrets" the best answer until now tell to use sqlite-crypt.

Reading sqlite-crypt docs, the new param for open the database is the pass-phrase. Of course, I don't want hardcode the password, so I was thinking what the best, simple and fast method to store that password?

+2  A: 

You pretty well have to store it in a user.

Otherwise you're just substituting some other security mechanism for the one you're asking about...


David's point in the comment on Infamy's answer is well taken. One should allow some flexibility, in case the user is handling protection at a lower layer... So, go vote for Infamy.

dmckee
A: 

You could try to do your very own hashing algorithm to store the password. however if someone rever engeener your code you could be in trouble

cheers

PERR0_HUNTER
Against any attack stronger than your kid sister, this is equivalent to putting it in a text file called "password.txt". Really.
dmckee
Coming up with your own hashing / encryption algorithm is almost always a bad idea.
Graeme Perrow
@Graeme - Let me paraphrase your answer: Inventing your own hashing and/or encryption scheme is ALWAYS a bad idea, unless you are working with a team of highly educated and experienced computer science and math geniuses who specializes in making secure encryption algorithms. :)
JohannesH
And you vet the algorithm to like-minded mad scientists and basically everyone knows what it is and still cannot be broken.
Flory
awe comon, do be so hard on me, I was just suggesting an alternative solution I like creating my own hashing algorithms =(
PERR0_HUNTER
+7  A: 

Some options.

  1. Ask the user for a passkey (aka they memorize one password to get to all their password) (good idea)

  2. Create a key on the first startup of the app, which is then hashed in your own unique way (bad idea)

  3. Use a mixture of the above, aka give users the options of one, or two (remember my password checkbox)

Infamy
+1 for #3. Some users may have alternative security schemes in place (e.g. full-disk encryption) that make storing the password in a configuration file an acceptably low risk for them.
David Zaslavsky
@David: good point...
dmckee
+2  A: 

Hardcoding is inevitable at some point, unless the password is only ever used interactively.

The best thing you can do in a password-in-file situation is make it damn hard to access it in the first place, and then limit what can be done with it if someone does find it. A rule of thumb is that you shouldn't give more privileges to a password stored in a string than one that you have to type at a prompt.

Ant P.
+1  A: 

On Windows you could/should use the DPAPI, the Data Protection API that provides storage encryption.
It's there just for this type of problem.

Encryption of the storage is based on either:

  • the user account, so only the logged-in user can access the data. This makes the data transferable to another PC with the exact same user credentials.
  • the machine, making the data only accessible on that particular machine setup and not transferable to another PC.

There is a dnrTV show with Karl Franklin showing exactly what's needed to implement this, and other encryption functions.
The source code from the show is also available on the page.

There are, of course, lots of other articles on that subject.

Renaud Bompuis