0

So, I wanted to make a login system with PHP, and basically what it would do would be to have a file for usernames and a file for passwords so when a user tries to log in, it just gets information from both files and matches the passwords.

However, the security side of me is saying that's an absolutely horrible idea. Is there a safe way that I could actually pull this off? If it had to do with encrypting the passwords, how would I do that in a safe manner?

  • 6
    Possible duplicate of [How to securely hash passwords?](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) – Konrad Borowski Mar 18 '18 at 13:43
  • 11
    *I wanted to make a login system with PHP*: Please, please, please don't. There's a lot of existing solutions; reinventing the wheel in a security context is *always* a bad idea. – Marcus Müller Mar 18 '18 at 13:53
  • 1
    Possible duplicate of [What is better, an established framework or a homebrew solution?](https://security.stackexchange.com/questions/31049/what-is-better-an-established-framework-or-a-homebrew-solution) – Neil Smithline Mar 18 '18 at 14:52

3 Answers3

2

The most PHP applications perform login by querying a database to validate the user-provided credentials. Databases have many advantages over plain-text files. Though the big issue here is not only the security of the database itself (of course you better use a strong password to access your database) but the security of your application in general.

That means that if you prefer/insist on using PHP for user-validation/registration etc... you better follow good and tested practices rather than re-inventing the wheel, not only for the validation but for every part of the application (since a seemingly minor bug can lead to full application compromise and database leakage). Now, as is widely known no system is 100% secure, so even if a security-breach occur for some reason you don't want all those user-credentials to be leaked in public. So the best way to avoid that is to save the hash (pick a cryptographically strong hash function like bcrypt etc...) of those creds rather than save them in plain text.

Finally, it's important to mention that there are web-frameworks (like Django, Ruby on Rails etc...) that by design offer a lot of security features out of the box (in my opinion PHP lacks in this part) while in PHP you have to code "carefully" and follow good practices.

Anders
  • 65,052
  • 24
  • 180
  • 218
game0ver
  • 585
  • 4
  • 12
  • 1
    and remeber don't put the files with this information inside webroot. – Jasen Mar 19 '18 at 09:04
  • @Jasen I couldn't agree more, and actually the OP has asked another question for exactly what you mentioned [here](https://security.stackexchange.com/questions/181815/how-secure-is-it-to-store-passwords-in-a-non-accessible-file) – game0ver Mar 19 '18 at 11:34
1

If you wanted to do it in spite of the contrary advice you already received, the standard way to proceed would be to set usernames and passwords as variables in dedicated PHP files. When a user tries to retrieve the files, the latter execute as PHP displaying nothing.

If you are considering to store passwords to validate logins, then you might want to store salted hashes instead.

Enos D'Andrea
  • 1,097
  • 6
  • 14
1

First, no matter where you store them, you need to make sure you properly hash them. That is priority number one. And note that is hash, not encrypt. Yes, there is a difference. A big difference.

As for where to store them, the obvious traditional choice would be a database. Let's compare storing passwords in a database to storing them in a file. Both choices comes with their own set of easy mistakes that can expose data.

For databases, you need to make sure to protect against SQL injection and harden the database server (don't expose it to the internet, use strong credentials, etc.).

For file based systems, there is a separate group of issues:

  • Put the file outside the webroot.
  • You need to make absolutely sure there are no local file inclusion vulnerabilities on your server.
  • Make sure the file doesn't end up in backups, git repositories, etc.

I'd say it's much easier to get this right with a database, since you have a clearer separation between code and data. But what matters in the end here is the implementation. A poorly written homebrew database library ridden with SQLi is worse than a well established and tested framework for files.

Still, I would expect it to be harder to get this right with files than with a database. And to be honest, getting a login system right in PHP is extremely hard to begin with. Forgive my pessimism, but most people who set out to do this fail and end up with insecure systems. Perhaps you should look into existing frameworks? That would greatly reduce your risk.

(Obviously, databases have some pretty big technical advantages not related to security, but I am leaving that out of the discsussion here.)

Anders
  • 65,052
  • 24
  • 180
  • 218