Should hardcoded passwords be salted/hashed?

Question

There are many questions on StackOverflow about simple, database-less login systems. I was about to suggest a salted hash approach on a recent one, when I thought: "does it really make sense to do that?".

I have been storing salted hashes on databases for years, and I understand why it's more secure: if the database is compromised, the information it contains won't allow anyone to log into my system (unlike if I were storing plain text passwords in the db).

But in a setup that does not involve a database, does hashing+salting offer any security benefits? The only reason I can think of is, if an attacker gains read-only access to my server-side code, it won't be possible to figure out any passwords. Is this a likely scenario? Because as soon as the attacker gains write access to the files, he can do anything.

So my question is: when setting up very simple, database-less login systems, should passwords be salted/hashed, or just stored as plain-text?

Answer 1

Well, as Steve Jessop already outlined. Source code can leak or is more likely to get in some hands. If you hardcode a password (what I understnand) then why not store it as a datastructure of two parts => the salt used and the hashed password. You know it but it never appears in source code. This is also what people do with DB connection strings or similar. Encrypt it with the key lying in the variable beneath it. Thus it never appears right in source code. maybe not even in memory dump unless just crossed.

Answer 2

I think the question is answered for you if you can figure out the answer to, "is my source code significantly less likely to be read by an attacker, than is a database?".

I would suggest that it is not -- perhaps your source is somewhat less likely to leak, depending how things are backed up etc. Even so I doubt that it's so much less likely to leak that you can neglect the risk, given that you do not neglect the same risk for databases. The reason that passwords in database should be salted/hashed isn't that there's some special property of databases that means attackers can view their contents[*], it's that attackers can get a look at all kinds of things, one way or another.

In fact source code might even be more likely to leak than a database, given that anyone working on the system might need access to the source, whereas not everyone working on a system necessarily needs access to the contents of the live DB. Not that I think your developers are dishonest (if they are, you have worse problems than the password leaking), just that the logistics around sharing source might introduce more (or just different) ways it can accidentally leak, than the logistics around backing up a DB.

Personally, in your situation I would create a small file on the server containing the hashed/salted password and approximately nothing else. Users installing different instances of the app can generate their own versions of this file, containing their own password, separate from the actual application code. They should lock it down with the same write-access restrictions as they do the source code.

Whether you call this file "a read-only database" or "part of the server code" doesn't affect how easy it is for an attacker to view it, although it might affect whether you refer to the password as "hard-coded".

[*] of course there are potential flaws that are special to particular databases, SQL injection attacks or whatever. Those are not the decisive reason why passwords in databases should be salted and hashed.

Answer 3

Yes, it still provides a benefit to hash and salt them. If the script's sourcecode is leaked people could otherwise simply use the hardcoded password or google for the hash and possibly find the input value. With a salted hash neither is possible.