Store Usernames and passwords in encrypted file instead of database

Question

So i know you are going to say this is bad, but i really dont like using a database as it is confusing and hard at the same time. I also think storing usernames and passwords in a file is bad, but both the username and password would be encrypted using md5. I dont think this is secure enough though though because im going to make it public. If you could give me tips on how to make this better please tell me.

Also You will only have two attempts per minute ;) Here is my idea: https://drive.google.com/file/d/0B19YDO3uT0ClaVZsYjRFRVZkUzA/view?usp=sharing

Also if you could give me examples on how and where to store the file in the webserver? i am not very good with php to be honest

Answer 1

Most databases can be accessed from the open web and you have to store the database password in a PHP file as well. Therefore in most configurations there is no security benefit using a database. It is just a more comfortable handling.

Hashing passwords is always a good idea and should be taken for granted. md5 is not a secure algorithm. Consider usage of password_hash() instead. Don't forget to intersperse a salt string to prevent rainbow table attacs when your hashfile gets stolen.

Any two-way-encryption would make your system insecure at all, because you would have to hold the secrets for decryption into plain text on the server an an attacker could steal everything he needs.

Limiting the login attemps is certainly not a bad idea, however, it is not as essential as you think. The main weak point is to get read access to the hashfile and then process an offline bruteforce, preferably with rainbow tables.

Answer 2

Here's what I would suggest. Don't use md5 because it's insecure and too fast without using iterations.

You really must have an SSL certificate for this to be secure from people seeing the password. Anything without a certificate is roughly equivalent to the user sending a raw text password. You have basically just changed what their password is.

As zaph noted, it's best practice to pin the certificate

On the client

• send the password to the web server (encrypted by the certificate for you)

On the web server

• Store a salt ( a unique random string )
• Hash the password using bcrypt or another secure hashing algorithm that also takes the salt
• Store the salt and the hashed salted password

Answer 3

You need to use a password hashing algorithm that also takes a salt and iterates such that the hashing takes substantial time such as 100ms. Typically you can use algorithms such as PDKDF2 , bcrypt , script or password_hash .

The password must be hashed on the server.

Use HTTPS for communication the password and pin the server certificate in the app, the pinning is important as it will protect against MITM attacks.

A DB may not be necessary, it is an issue of lookup time and disk I/O. You can start with a flat fine and migrate to a DB if/when the performance is needed. "Uncle Bob" Martin delayed using a DB in FitNesse and in the end found a flat-file solution was all that was needed.

Note: Essentially all simple hash methods such as SHA2, SHA3, etc. are to fast and need many iterations to increase the calculation time. The time is important so an attacker can not try hashed quickly. A random (not exactly unique) salt per password is needed to eliminate the use of rainbow tables of pre-calculated hashes.