1

Setup: Say I'm properly generating a password hash (e.g., concatenating it with a /dev/urandom salt and a local secret and hashing it with bcrypt), now I go to store the result in a "user information" file containing name, username, email, salt, and hash result on Linux. Say I set proper permissions on the file to protect it, and that I generally take proper precautions to protect my server from attackers/intruders.

Question: Is it important that I do anything else to secure the file itself? Is plaintext encoding fine or should another encoding be used to attempt to obfuscate it? Should it be encrypted, and a password required to decrypt it?

Update from comments:

  • There was a good (at least partial) answer that hashed passwords should be stored in protected areas of the network instead of DMZ whenever possible.
  • Also the local secret should be stored separately from the hash file, so that an attacker that got one wouldn't automatically get both. An HSM (Hardware Security Module) was recommended.
  • The point was made that a file may be vulnerable to a URL-escaping attack, unlike a database.
  • Not in a comment, but I also found this related thread helpful, the additional relevant advice seemed to be to make sure to store the file in a secure location and to err on the side of encrypting it.
  • What? No database? Where are you going to store the lockout counter? – John Wu Mar 15 '17 at 18:48
  • @JohnWu for this particular application I expect very low volume/traffic and probably don't need a database. But if I did use a database, wouldn't the question still be at least somewhat valid? E.g. data in mysql files can be read too, or what if I had a transaction log or backup file of the database. – jrefior Mar 15 '17 at 18:59
  • what other user information is stored? Credit card numbers? Addresses? – Tim Mar 15 '17 at 19:10
  • @OP: Same question, sure, but different answer. DB will be protected zone whereas flat file may be in DMZ. Flat file is potentially vulnerable to URL escaping attack while with DB you have to worry about SQL injection. Also, if you have no lockout counter, you may as well publish the file because a hacker can brute force passwords almost as easily. – John Wu Mar 15 '17 at 19:13
  • @Tim updated question with expected information. Probably nothing more sensitive than name/username/email. – jrefior Mar 15 '17 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.