Page 2 - How to program a basic but secure login system using PHP and MySQL

Yeah, but that would be only one user's password. If they are targeting a specific user then it's hard to prevent an attack against them, but you can fairly easily prevent a widespread attack.


Again, security is not about either-or choices. An application-level salt, a per-user salt, and a strong algorithm are all important. But for someone who doesn't know how to make a login system these are 200-level topics: let's just focus on teaching them the principles of the system first.


Yeah, which is why you try really hard to make sure you cover all your bases and don't have any such weaknesses. But saying "don't expose my database in any way I shouldn't" is easier said than done.

Pretty strange loophole if they can get the hashed version of just one user's password and that's it. If that's all they have then I'd agree, but if they have a way into that, chances are they're going to have a lot more, too.



True, it's an advanced topic, but one that the example leads in to. If you figure that a lot of new programmers are going to use the example, it's important for them to understand what it means. And as it's advertised as a "secure login system", it's important to note how it secures the system and it's weaknesses.

You could buy the best alarm system in the world, bar your bullet-proof windows, have a security door and a 20 foot wall around your house.... but all that's going to be irrelevant if you go to grab some fast food and leave your front door wide open.

Layered security is fine but it's more optimal to layer it in such a way that getting past one layer doesn't mean getting past multiple at the same time. The salt in the example doesn't strike me as having any relevance in your brute force model since anyone with access to the hashed password will likely have access to the salt, too. They get past both layers of security at once, so the salt's not actually adding anything.

A good layered approach IMO would be:
1. Hashed passwords in database
2. Application-level salt
3. Lock user after X failed login attempts
4. Block IP after:

- Repeated failed login attempts (especially for different usernames)
- Repeated bad session matches from cookies (especially for different usernames)

These address the two brute force scenarios I can think of.

In order to brute force a hashed password, the user would need access to both the database and application. If they can do that then there's no stopping them in your application, anyway.

They can try to brute force your login form but will be locked out quickly by username or IP. Preferably the latter so they can't torment your users.

And if you're on a shared server/database, well... just accept the fact that the system admins will always be able to crack your system.



I've found MySQL exceptionally easy to secure. Out of the box you can limit database users by Host, which right there locks out most would-be hackers. If that sounds too easy, just throw IPTables up to keep them away from the MySQL service altogether.

I was thinking more about programmer error. In code. Not escaping everything, wrong data types, incorrect settings, faulty logic...

dmittner, you're really on the wrong track here.

Focusing on the login form doesn't make sense, because that's not the weak point. In fact, trying to brute force the login system is the most stupid and inefficient attack possible, because it's simply too slow and will soon be detected.

The standard attack scenario which actually happens in reality is an SQL injection (as requinix already said). So you assume that all user data has been exposed, and now you try to make brute forcing the hashes as hard as possible. The key to this is using unique salts and a slow hashing algorithm.

The purpose of a salt is not to be a secret addition to the actual password. This is a completely different concept sometimes called "pepper". A salt is meant to prevent attacks on all hashes at once. It must be random and unique for every hash, but it does not have to be secret. In fact, the common practice today is to store the salt as plaintext together with the hash.

The main security comes from the unique salts. A "pepper" will at best provide some additional security.

Many people think that security is all about keeping things "secret". But that's not the case. You should rely on secrecy as little as possible, because most things cannot really be kept secret.

I think it's the ultimate weak point. It might not be the fastest, but trying to gain access to an administrator's account will open all the gates, and going through the login form means "playing by the rules" and slipping past all the salts, all the peppers, all the rehashes, and any other obstacles your code throws up for protections. Making them useless.

And they'll only be detected if you have logic watching for them.

That's why I suggested above that a salt/pepper won't offer much protection without also banning IPs based on repeat login failures. And considering a lot of sites do this (and more in that area) they obviously see that the legitimate login path is an insecurity.

Protecting the left flank with all your forces won't protect your right flank from an assault.



If you're assuming that all user data is exposed and if they're trying to attack all hashes at once... what's stopping them? If they have the unique salt for every hash, then they can include it in their brute force attack logic.

That's why I suggested a hard-coded pepper before. At least then, if your database is compromised, they won't get anywhere comparing their password library against the hashes: They'll be missing half the components to the hashing/encryption and they might not even know they're missing it.



Thus my suggestions before. They come down to two strategies:

1. Put critical password pieces in different places so they can't all be compromised at once. The provided example puts both critical pieces in the same place. All the eggs in one basket. If one is compromised, the other probably has been, too. So keeping with the theme of the example being simple, I suggested an application-level salt instead of a database-based one.

2. The other protects the legitimate login process from just being sent the password library one at a time for specific accounts.

The third path which has really only been implied is to intentionally take a while; use an algorithm that naturally takes a second or two to process. Short enough that using it at user login won't be too annoying, long enough to be debilitating to any brute force attempts--whether based on compromised data or going through the login logic.

I'm not averse to any of the stated strategies but few people are likely to employ all of them, so they'll need to select those with the most coverage and the most redundancy.

Nice discussion.

Regarding using of salt: my understanding of using a salt is to prevent searching for the hash in a rainbow table to get fast access (compared to brute-foce) for the weak password.

Any other purpose by using salt I have missed out?

In theory this might work. But it's not a realistic scenario.

Trying out the passwords through request and response is so extremely slow compared to a local attack that the passwords would need to be really weak to be brute forced in reasonable time. You'd also have send billions of requests without being noticed.

If the admins fail both at creating a secure password and monitoring network traffic, then it's probably too late, anyway.

I'm not saying that a login limit is useless. It does make sense to protect weak user passwords. But you shouldn't focus on the login form, because it's simply not what an attacker will go after.

Banning IPs is also rather problematic, because it can affect completely innocent users (if they're behind a router or a proxy server).





Yes. But if you've used a good hashing algorithm, brute forcing will take a lot of time and/or money.

Also note that this is the worst case. So even if all information has been stolen, the attacker still has to brute force every single hash.

That's not the case with your approach. As soon as the pepper is known, you can attack all hashes at once.





That's a naive assumption. If the attacker was already able to get your whole database, why shouldn't he be able to also get the pepper?

Also the pepper cannot really be secret. It must be stored in plaintext in some file, readable by the webserver (unless you use a persistent application and store it in the RAM or something).

Of course you can use a pepper in addition to unique salts. But don't use it as a replacement (for the reasons I explained above).

By the way, that's not just my personal opinion. This is the current standard approach as suggested by people who know more about security than we do.





Your suggestions are not wrong, but they're rather "bonus features" you can apply for some additional security. They're not sufficient.

My suggestions would be:

• Use a specialized hashing algorithm like bcrypt or PBKDF2 with a unique, random salt for every password. The salt doesn't have to be secret.
• Be as restrictive as possible with regard to user rights. Everybody should only have those rights he absolutely needs (this also applies to "technical users" like the database user). For example, I don't even allow the db user to directly access tables. He can only call predefined functions.

I am having issues with the login. I use the registration form to create un: and pw: and then when I try to use it for the login it always fails. On this particular page I am not requiring a username, so I set the value and then kept everything else the same.

I'm currently using this login system on my site and I think it's great. I'm a new learner to PHP and this is a great way to enhance my learning skills with the comments explaining what each function does. I have a few additions I would like to make, however - but being a new learner I would have no clue where to start right now.

Firstly, I'd like to add the function where they register and are required to enter their email address, and have the ability to edit their account details (username, email and password.)

Secondly, I would like to create a members page. By that, I mean a page which gets all of the usernames from the database and displays them all (users.php).

I am looking to develop this system but I obviously need a little help. I'd greatly appreciate if you would help me do one of the above (or even both) in order for me to understand a little more about PHP and to use it on my site.

Thank you, any input appreciated.

Jackage95, may I recommend that you make a post in the actual forum, I think you've not had any replies as this would only be seen by someone who is specifically reading this thread, whereas a new thread in the PHP FORUM should yeild more help.

I've been planning to post an update with some of those things but haven't had time recently.

I have updated the original tutorial to incorporate the password storage security enhancements recommended by Karl-Uwe Frank and the two additional features, editing of accounts and a members list, recommended by Jackage95.

I know that in your code you have this:

// Note that die() is generally a terrible way of handling user errors
// like this. It is much better to display the error with the form
// and allow the user to correct their mistake. However, that is an
// exercise for you to implement yourself.

I am wanting to implement errors displaying on the page itself. I am pretty new to PHP.

I am thinking I could submit the form to itself? Is that what is already happening? Could you point me in the right direction on how to make this happen?

Thanks for the update looks good! if you ever update it again i would love to see a simple members profile with profile image. I'm just putting that out there lol again thanks.

Hello,
First of all I find this script very usefull in learning more than basic php programming.
I have one question though: now that it is so secure, that not even the admins knows the users password, what will a user do, if he forgets his password?

This is not an attemp to be a smartass critics or anything, I'm just trying to learn