5

I am working on a small java desktop application that stores users passwords on a .db file. When the user creates a new database, the user must create a master password for that database, in order to access any facebook or twitter passwords that they may choose to store on it. My question is, where and how should I securely store the master password?

My idea was to encrypt the master password and add a salt before storing it, then store the password on an encrypted text file or .db file, then read of it when a user attempts to access the database. I am just looking for guidance on whether this is a good idea, or if there are any better alternatives.

The application a desktop application not a web application.

kazuwal
  • 1,071
  • 17
  • 25
  • instead of encrypting, it hash it... I feel its more secure to use a hash instead of encryption. – codeMan Nov 15 '13 at 14:11
  • @codeMan Mhmm, and how do you obtain this hash? SHA IS encryption – Cruncher Nov 15 '13 at 14:16
  • there are lot of utility classes for that, just decide on a hashing algorithm and use it. For example something like MD5 – codeMan Nov 15 '13 at 14:17
  • @codeMan SHA-2 should be used instead of MD5 (or SHA-1) for anything security related. – frostmatthew Nov 15 '13 at 14:18
  • 2
    If this application lives entirely on their desktop, then it is impossible to fully secure it. This is also why DRM is impossible. If your source code can read the password, then somebody that knows how to read byte code, can also read the password. – Cruncher Nov 15 '13 at 14:18
  • @Exupery sure you could use that too... that is why I mentioned md5 as an `EXAMPLE` – codeMan Nov 15 '13 at 14:21
  • 4
    @Cruncher this is why you use one way hashes (ideally salt+hash) passwords instead of encrypting them...the application cannot "read the password" - it can only tell if the password the user entered is valid or not. – frostmatthew Nov 15 '13 at 14:22

2 Answers2

4

The most secure way to store passwords is in such a way that even you (your app) doesn't know what the password is. This is accomplished by using a one way hash. As the name implies this is one way, there is no way to "un-hash" a hashed value and see what the original value was.

One of the important characteristics of a cryptographic hash is that hashing a value will always produce the same hash.The SHA-2 (256) hash of "The quick brown fox jumps over the lazy dog" will always generate a hash d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592 - while there is no way to take that hash and determine what the unhashed value is a hacker with a rainbow table could see what it corresponds to (this is why weak passwords, even when hashed are still vulnerable, every rainbow table in the world is going to have the hashes for 123456).

So before hashing the password we add a salt (ideally a different salt for each user). If before hashing "The quick brown fox jumps over the lazy dog" we add a salt (let's just use the word "salt" as a simple example) we would now hash "saltThe quick brown fox jumps over the lazy dog" and get b369837c6389d8dddb06cb669961b0ab80f5166cc8cebcfaf9734ed009c31e8b as our hash.

The salted hash is what you should store (however/wherever makes sense for your application) and check against. So when a user first creates an account you will:

  1. take the password they choose and add the salt
  2. hash it (using a collision free cryptographic hash, such as SHA-2)
  3. store the result

When the user attempts to login you will:

  1. take the password they input into the login form and add the salt
  2. hash it
  3. compare it to what you have stored

If it is not identical they entered the incorrect password, if it is the same you know they entered the correct password and you can log them in.

frostmatthew
  • 3,260
  • 4
  • 40
  • 50
  • Thanks @exupery.. Do you have any thoughts on where the file with the passwords stored on should be stored? and what format the file should be so i can encrypt the file as well? – kazuwal Nov 15 '13 at 15:36
  • If you're making an application to store Twitter and Facebook passwords (as your question suggests) you really shouldn't be storing them at all since there's no need; you can (and should) make use of their APIs (and thus handle authentication with them via OAuth). If you are going to attempt to store passwords securely it's important to remember there is no absolute security. The file format doesn't matter and you should certainly encrypt and/or obfuscate the data to protect if from a casual observer, but if the machine is compromised you (and the user) should consider that data compromised. – frostmatthew Nov 15 '13 at 16:29
  • 1
    Thanks, I am looking into OAuth, it seems much safer – kazuwal Nov 15 '13 at 17:35
0

Suppose you have a .db file which contains facebook or twitter passwords. You store them in an encrypted form and use the master password as an encryption key to encrypt/decrypt your .db file. The master passsword in this case is entered by user and is not stored anywhere (you can keep it in memory while your application is running). To validate the master password when a user attempts to access the database you can decrypt with it some string constant.

digr
  • 1