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.
jrefior
  • 111
  • 3
  • 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](https://security.stackexchange.com/questions/141315/are-mysqls-database-files-encrypted/141325#141325), 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
  • @JohnWu Appreciate your points about lockout counter and DMZ. Let's say there are lockout counters both by incoming IP address and by login, and they are stored separately from this file. And I take it as an assertion that hashed passwords should be stored in a protected area of the network if possible - good point. – jrefior Mar 15 '17 at 19:18
  • Make sure that if the hash file walks that the local secret doesn't too. Probably want to store that somewhere else, even protected by an HSM. – Scovetta Mar 16 '17 at 02:21
  • @JohnWu Actually, most of the brute-forcing is done offline...lockouts are basically for brainless but persistent people who would indulge themselves in manual labour to extract someones information. – user633551 Mar 16 '17 at 16:46
  • I think you'd see a lot more hackers use automated tools to harvest passwords online if sites did not commonly enforce a lockout. – John Wu Mar 16 '17 at 17:33

0 Answers0