Security and conventions. DB or File?

Question

Let me start off by stating I know the benefits of a database but that is not the question. I want to know if the security makes sense with an added benefit of speed.

By using PHP 7.0,

Test 1: I have a database setup with a table called user, with an id field and password for an example. I use the PDO extension to query the database by id. The request took o 0.0005719 microseconds to complete.

Test 2: I read a local file that all it contains is a password hashed.

The request takes 0.00005912 microseconds to complete.

Please note: in both cases the passwords are hashed using php's password hash function. As this is a security fourm I want to state that as well. Also for concurrency the file is assumed safe to be read only by one person at one time at login only.

Either way, as it would be used to login only, not get details, would it be secure? (The files are NOT stored in web root). So somebody would need a server login, or the php acting as a middleman to read the file. The database is mysql and requires a server login plus mysql login.

Question: are the speed benefits for using a file instead of a database warrant good grounds for using a file or keep it in the database? Does this pose any security risk on a production environment?

Update - 23-02-2017 Let me state a few things. 1, A "full" user is not stored in the file, only a password already hashed. No need for indexers because when a user logs in a md5 hash of the Username would be directed straight to a file on the local system. (Username cannot be changed). This would allow for quick logging in, without a database query. 2, The test was conducted with the data already store just the time getting the data was tested. 3, It is microseconds, as per php microtime. The operation was iterated 100 times, then a difference was taken and averaged. 4, this is strictly hypothetical.

Answer 1

If the passwords are salted and hashed then there is no real value in them to an attacker. Go with whatever is simplest to manage from a development and maintenance point of view.

Answer 2

On the security side of the question I upvote James Baxter's answer.

Performance-wise, if some tenths of a microsecond are really an issue, then probably you'd be much, much better served by taking a long hard look at the whole authentication process. The actual back-end is likely a drop in the ocean when compared to authentication routing and all that it involves.

Probably unnecessary worries

If you really need that speed, then you're probably well into C10K country, and your specific needs will probably be too domain-specific for me to give suggestions without a much deeper understanding of what the problems might be.

In such a case, however, I would recommend that you carefully analyzed and measured all bottlenecks and possible performance hits. There are many solutions to the "fast data recovery for authentication purposes" problem, and most come unavoidably with more problems of their own.

Going "file" over "database" (or memcached, or Redis, or mongodb vs MySQL, or...) to squeeze some performance might well come back and harm said performances some time down the line.

In small setups it doesn't really matter too much one way or the other -- but when it does matter, you don't want to only rely on one speed parameter. Again as James Baxter hinted, you also need to consider maintainability - and then there's expandability, scalability, reliability, locking issues in case of updates, and so on.

Answer 3

Are the speed benefits for using a file instead of a database warrant good grounds for using a file or keep it in the database? Does this pose any security risk on a production environment?

In the portions of microseconds realm, absolutely not. This gets much more apparent when you get lots of entries which then need to be indexed, gain value from caching, are changed by users, etc. For the sake of any future scalability, use a database.

There's a further security benefit to using a database, and that is setting it properly to never disclose the password hash. If the webserver queries the user's salt, computes the hash, and sends the hash to a database trigger asking for the result of a compare function, then you can eliminate (via table query permisisons) the ability of the webserver to ever read the hash no matter how compromised it becomes.

Answer 4

Your performance analysis is flawed. Leaving aside the fact you appear to be confusing seconds and microseconds, measuring only the elapsed time for a single instance (or consecutive instances) is not a realistic measure of throughput or capacity. Capacity does have some relevance to availability, so forcing sequential access can only have an adverse impact on security by reducing the availabilty of your service, although I suspect you mey run out of network bandwidth before you run out of processing.

A further concern is that if you are storing all your user accounts in a single, flat file then you will have problems with scalability - the performance will likely reduce with volume.

DBMS are usually complex and provide network access (this is sometimes true of filesystems as well) so it's likely that using a dedicated dbms instance for authentication may increase the attack surface of the system.

But overall, the differences in Security are trivial compared with the impact on functionality and scalability.

It's worth pointing out that you should not be favouring a password hashing mechanism based on how fast it is unless you can ensure very high entropy passwords; you don't want to make it too easy to brute force the password offline.