Sorry I've been gone for so long, I've been working on a ton of various projects.

One of those projects no longer needs a huge database of members for a login script. In fact, only one section still needs password protection for only one account. I've found a couple of scripts that use a hardcoded password with cookies in the following format:

form
input password
submit

php checks password against predefined $password variable
if the submitted password = $password, cookie is created, user is logged in.

password protected pages check if cookie exists, redirects if not.

I'm pretty sure that explains enough, but let me know if you need more.

What I'm wondering is how secure this is. From what I understand, php files can only be read if you download them via ftp, so there should be no way for someone to see what I've defined the password variable as, correct?

Also, from what I've read, cookies & sessions both have potential security flaws, so neither is 100% secure. The only computers that will be used to log in to area require passwords to login, so I'm hoping cookies will be an ok choice for this.

Thanks in advance!
-Jorge

    1. The password is transmitted in the clear and hence is vulnerable to being intercepted.

    2. Your password protected pages only check for the existence of the cookie. An attacker may forge the cookie and circumvent your authentication scheme.

    3. If you are storing the password on the cookie, then an attacker cannot just forge any cookie. On the other hand, the cookie may be left behind after the session, only to be retrieved by a malicious next user of the computer.

    4. Hard coding a password directly into the script makes it vulnerable if for some reason the server fails to parse the PHP code.

    The solution for #1 is to use SSL/TLS, but this may not be economically feasible depending on the nature of the website and data being protected. A solution for #2 and #3 would be to use sessions with a session cookie, though then the danger is that failure to log out on a shared computer could also mean the same problem, though now the fixed password is no longer in danger (but your data is!). Problem #4 could be avoided by storing it in a file in your "non web space", typically above your root public HTML directory, and then retrieving the password from that file in your script.

      lol, maybe it would be easier to just stick with mysql. Thanks for your help laserlight!

        maybe it would be easier to just stick with mysql.

        To be fair, the first three points apply to an authentication scheme that uses mysql or any other database system to store login credentials, and the fourth point applies to database user credentials. Using a database management system does not suddenly make your script secure.

          I understand. Mysql has encryption, and there are a ton of examples available to learn from, but I realize nothing is 100% safe.

          Thanks again.

            Write a Reply...