#16
  1. Jealous Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,449
    Rep Power
    9406
    Originally Posted by dmittner
    But in the context of the original code, if they've gained enough access to get the hashed password, wouldn't they likely have gotten the user's salt, too? If they have both then they could still brute force it.
    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.

    Originally Posted by dmittner
    It seems an application-specific salt (ie, NOT defined anywhere in the database) would be a better option. That would be more akin to re-hashing X amount of times; something only the application knows about. But then it would be of minimal value to use both; one or the other would suffice.
    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.

    Originally Posted by dmittner
    Secure practices would mean not exposing your database in any way. If they can't get the hash to begin with, they'll be at a loss. And if they *can* get the hash, chances are you've got a pretty big security issue elsewhere which would be of more importance to correct.
    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.
  2. #17
  3. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by requinix
    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.
    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.

    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.
    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.

    But saying "don't expose my database in any way I shouldn't" is easier said than done.
    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.
  4. #18
  5. Jealous Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,449
    Rep Power
    9406
    Originally Posted by dmittner
    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...
  6. #19
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    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.
    Last edited by Jacques1; August 13th, 2012 at 04:29 AM.
  8. #20
  9. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by Jacques1
    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.
    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.

    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.
    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.

    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.
    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.
  10. #21
  11. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,800
    Rep Power
    1959
    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?
  12. #22
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by dmittner
    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.
    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).



    Originally Posted by dmittner
    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.
    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.



    Originally Posted by dmittner
    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.
    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.



    Originally Posted by dmittner
    Thus my suggestions before. They come down to two strategies:
    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.
  14. #23
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2012
    Posts
    1
    Rep Power
    0

    login issues


    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.
  16. #24
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2012
    Posts
    1
    Rep Power
    0
    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.
  18. #25
  19. Confused badger
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2009
    Location
    West Yorkshire
    Posts
    1,200
    Rep Power
    492
    Originally Posted by Jackage95
    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.
    "For if leisure and security were enjoyed by all alike, the great mass of human beings who are normally stupefied by poverty would become literate and would learn to think for themselves; and when once they had done this, they would sooner or later realise that the privileged minority had no function and they would sweep it away"
    - George Orwell, 1984
  20. #26
  21. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,314
    Rep Power
    7171
    I've been planning to post an update with some of those things but haven't had time recently.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  22. #27
  23. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,314
    Rep Power
    7171
    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.

    Comments on this post

    • badger_fruit agrees : Nice work!
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  24. #28
  25. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    3
    Rep Power
    0
    Originally Posted by E-Oreo
    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?
  26. #29
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2006
    Posts
    68
    Rep Power
    9
    Originally Posted by E-Oreo
    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.
    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.
  28. #30
  29. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    6
    Rep Power
    0

    What if the user forgets his password?


    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

IMN logo majestic logo threadwatch logo seochat tools logo