6

I'm creating a program (in C++) that will password protects its user's database (.dat) file. I'm confused on where to store the password? In the user's database file or somewhere else.

I'm new to this concept. I don't know where a program should store the hashed password. I've been thinking for this from a long time.

I have a question too. If a program stores hashed password in the database file (along with users data) is it possible for an attacker to modify the hash inside the file to some common hash like the hash of the text 'password' so that the password becomes 'password'?

Edit: Okay! I've somewhat understood the password storing concept. This is what I've understood:

Get the password from the user

Hash it (I will use SHA-512)

Store the hash in the database file

Done

Probably, I didn't understand the symmetric hash concept. Please explain me in an easy way. And the question I have is... I'll better explain it with an example.

Assume this is user's file's content

thisismydatabasefile

User decides to add a password. He types in the password and we hash it. The generated hash is somerandomhash. We encrypt the file with somerandomhash as the password and the hash is included in the encrypted file. So now the file content is

encryptedfilesomerandomhash

Imagine the attacker got the encrypted database file. He knows that the hash of the password is "somerandomhash". He now modifies the password hash 'somerandomhash' to something common like 'somehashthatheknows'. So what is a better way to store a password.

For ease, how do programs like zip, 7z, rar etc store passwords inside a archive file?

Improve this question
6
  • "If a program stores hashed password in the database file..." Yes, and this is how reset password functions are working.
    – Nemanja Boric
    Sep 14, 2013 at 10:58
  • 2
    That's one reason why you add a salt to your password before hashing. Helps only as long as the attacker can't find out the salt string of course.
    – thorsten müller
    Sep 14, 2013 at 11:04
  • 1
    @thorstenmüller Huh? Salting is useful even if the attacker knows it, because it multiplies the attacker's work by the number of distinct salts (and they should be distinct). Moreover, since you need to store the salt to verify the password, you usually can't avoid the attacker learning the salt once they learn the hash (if you had a more secure location where you stored the salt, you would have just stored the hash there to begin with).
    – user7043
    Sep 14, 2013 at 14:28
  • 1
    Ranbir Kaif, could you elaborate on the scenario? Who is involved, what might they do, and which of these actions do you want to prevent? Try applying concepts such as confidentiality and data integrity. It sounds like the attacker has access to the .dat file, so just prepending a hash to the plain text won't help. Even if your code reliably refuses to handle .dat files without the right password, any attacker can just modify the contents (including a password hash and salt) directly.
    – user7043
    Sep 14, 2013 at 14:38
  • If the first part of the question is answered, please ask a new question with the new information. There are now two questions in this question - "is it possible for an attacker to modify the hash inside the file to some common hash like the hash of the text 'password' so that the password becomes 'password'?" and "how do programs like zip, 7z, rar etc store passwords inside a archive file?" - these should be separate questions.
    – user40980
    Sep 15, 2013 at 14:38

3 Answers 3

Reset to default
6

You correctly identified that storing the hash anywhere on the disk makes the password vulnerable to attacks such as breaching file access control, known cypher-text attacks, or chosen cypher-text attacks.

Security Solution: Do not store a hashed password on the disk.

Since your database is just a file we can use the general way to securely password protect a file on disk.

Algorithm To Securely Password Protect A File:

  1. Have the user input a password at runtime for the file. (database in your case)
  2. Hash the password. (I'd use SHA-256)
  3. Use the hash to derive a symmetric 256-bit key. (I'd use hash directly as the key)
  4. Use the 256-bit key to encrypt/decrypt the database file on the disk. (I'd use the AES algorithm)

Major Pro: Database encryption key is generated at run-time and never stored on the disk.

Minor Con: Encryption and key derivation becomes implementation specific and laborous to implement.

You get to decide whether the required security for the application is worth the time to implement the security protocols correctly.

Improve this answer
3
  • The challenge is determining that the password in fact is decrypting the file. In some cases there are reasonably simple checks that can be done with the decrypted data to ensure that the data is correct. I have also worked with systems that included well known data or well known checks into the data file. That data can be used to determine if the password is in fact correct. It is best if there is some inherent check to the structure or contents of the file, as well known data in the file can be used with a plain text attack.
    – Bill Door
    Sep 15, 2013 at 17:55
  • I believe it is also the case that many decryption algorithms can detect that the data being decrypted is incorrect.
    – Bill Door
    Sep 15, 2013 at 17:56
  • Put a table in the database with data to verify the correct decryption. Also, I'm pretty sure your DBMS will alert you if the database file your attempting to load is incorrectly formatted (not correctly decrypted).
    – recursion.ninja
    Sep 18, 2013 at 18:23
1

You leverage the OS features for password storage. For example, on Windows you'd install your program with a dedicated user account and it would know the password for itself, you'd then use it to decrypt your database file. Any attacker would have to then run the program as that user, or if they'd stolen the DB file then they would not have access to the password anywhere - the program itself doesn't have access to it. Password management then becomes an admin task associated with user accounts, not something unique to your program.

Brute force decryption obviously would still be possible attack vectors, but for that to work they'd have to steal the DB file and hack it "offline".

As an example, think of how webservers give access to a DB that requires a password without letting anyone else have access. The password is stored, in plain text usually, in a text file on disk. But that file is not accessible to anyone other than the webserver using what file protection the OS provides.

Improve this answer
1

Why put the password, in ANY form, on an externally-accessible database on an externally-accessible machine?

The RADIUS protocol was specifically designed to, among other things, allow one protected machine to serve any number of externally-accessible machines, providing authentication and authorization services. The externally-accessible machine receives the login credential from the user, and forwards it to the RADIUS server. The RADIUS server knows full well that it is ONLY allowed to handle requests from known machines. When it receives a properly-authenticated request from an authorized source, it does its thing, and sends back a Yeah Verily/Hell NO! answer, or a more detailed one that says what this user is or is not allowed to do.

Improve this answer

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.