Basic concepts for a secure login form?

[Joseph_Sliker]

Hi; I've been creating work-related data pages for several years now, but I believe that my comprehension of user-logins is pretty simplistic. (ie. present user with a username text box, a password (password type) box and the login button on a method=post form, convert the incoming pword via MD5 and run the username/(MD5password) query against the entries in my user table).

My data pages are not likely to be of any interest to anyone outside of our workplace, but I am gradually becoming interested in doing this stuff a bit more professionally/securely.

I'm suspecting that sending the entry of the password box over the web is really not secure at all, but what do I need to understand and do in order to improve this? I think I'm lacking some very basic concepts here.

[laserlight]

Joseph Sliker wrote:

present user with a username text box, a password (password type) box and the login button on a method=post form, convert the incoming pword via MD5 and run the username/(MD5password) query against the entries in my user table

One concern is that users tend to reuse passwords (on different websites), so in the event that your database is compromised, it would be nice if the attacker would have a hard time trying to login with their password elsewhere. To this end, a user specific salt is stored with the password. You would query for the user by username to get the hashed password and salt, then hash the password provided with the salt and check if it matches the hashed password stored.

For the hash algorithm to use, search the Web for scrypt and bcrypt. If it is infeasible to use such algorithms, then consider the repeated hashing of the password (or after the first application, the result of the hash) with the salt.

Joseph Sliker wrote:

I'm suspecting that sending the entry of the password box over the web is really not secure at all, but what do I need to understand and do in order to improve this?

Yes, by right you should be making use of SSL/TLS, otherwise the data submitted is sent in the clear.

[laserlight]

Joseph Sliker wrote:

present user with a username text box, a password (password type) box and the login button on a method=post form, convert the incoming pword via MD5 and run the username/(MD5password) query against the entries in my user table

One concern is that users tend to reuse passwords (on different websites), so in the event that your database is compromised, it would be nice if the attacker would have a hard time trying to login with their password elsewhere. To this end, a user specific salt is stored with the password. You would query for the user by username to get the hashed password and salt, then hash the password provided with the salt and check if it matches the hashed password stored.

For the hash algorithm to use, search the Web for scrypt and bcrypt. If it is infeasible to use such algorithms, then consider the repeated hashing of the password (or after the first application, the result of the hash) with the salt.

Joseph Sliker wrote:

I'm suspecting that sending the entry of the password box over the web is really not secure at all, but what do I need to understand and do in order to improve this?

Yes, by right you should be making use of SSL/TLS, otherwise the data submitted is sent in the clear.

[dalecosp]

Another consideration might be CSRF (Cross Site Request Forgery) and XSS (Cross Site Scripting) attacks: http://phpsec.org/projects/guide/2.html

[Bonesnap]

Four quick things:

• Salt your passwords (uniquely).
• Don't impose password restrictions on users (at most include a password strength metre and let them decide)
• Don't use MD5 or SHA-1. They are not secure, despite their wide-use.
• Don't use the MySQL extension and instead use MySQLi or PDO for your database queries.

[Joseph_Sliker]

Okay...
I have been using mysqli for the past couple years. Check
I let users select their own passwords (and insist they DON'T use their main passwords on the main enterprise system) (my stuff is just a little sideshow....that ends up being very useful to a lot of folks who have no idea how to get the real IT folks to do anything for them). (Sadly, they often ignore my insistance).
Big question: Explain the "salt" concept, please? Once I'm clear on that, I'll try to wrap my head around SSL/TLS...I know I encounter it on other websites....I'm just clueless how to set it up for mine at this point.

[jeepin81]

Here is a very basic example:

$salt = 'YourSUp3rUniq3S@lTSt!ng';
$pass = 'doggy';  // user supplied password
$passSalted = sha1($salt.$pass); //concatenate the salt & user supplied pass

You could then save you salt phrase in your db or off your web root. If you google "php salt" you'll see a bunch of examples.

[Weedpacket]

Note that the salt should be different for each user - it's more secure than using the same salt for all, because (a) even if two users have the same password, the hashes will be different, (b) an attacker trying to build a dictionary (a list of hashes for strings that start with "YourSUp3rUniq3SAltSt!ng", say) would only be able to target one user at a time. This could be done by, say, including the username as part of the salt (obviously, don't use something that might change!).

Further, the salt should be a string of arbitrary bytes - there are 256 possible bytes and there is no reason to restrict yourself only to those between 32 and 126 inclusive.

Oh, and I think I'd prefer to use something from the [man]hash[/man] list.

[laserlight]

Bonesnap wrote:

- Don't use MD5 or SHA-1. They are not secure, despite their wide-use.

Since neither MD5 nor SHA1 has been broken with respect to preimage attacks yet (to the best of my knowledge), they are technically still secure if you allow arbitrary length passwords (and use a salt, so collision attacks won't work). Problem is, people don't normally use long passphrases that approach the length of short stories.

Weedpacket wrote:

Oh, and I think I'd prefer to use something from the hash list.

Several of the available algorithms are broken, so if you do want to use hash(), then I suggest picking one in the SHA-2 family (e.g., sha256) or whirlpool, then doing the repeated application of the hash function (i.e., key stretching) that I briefly described.

[Derokorian]

I salt with a randomly generated string of characters stored in the database, an application wide salt and the username/email. So if they login using their email my check might look like this (with error checking skipped for brevity):

$sql = "SELECT salt,pass FROM users WHERE email = '$_POST[email]'"; // Don't ever put user supplied data directly in a query like this! 
$res = $mysqli->query($sql);
if( !$res || $res->num_rows < 1 )
{
   $login = false;
   $msg = "No user found by that email";
}
else
{
   $row = $res->fetch_object();
   $posted = hash('sha256', APP_SALT . $row->salt . $_POST['pass'] . strtolower($_POST['email']) . APP_SALT);
   if( $posted == $row->pass )
   {
      $login = true;
      $msg = "Login successful";
   }
   else
   {
      $login = false;
      $msg = "Username/Password mismatch.";
   }
}

if( $login )
{
   header("Refresh: 5;url=http://www.example.com/userhome");
}
echo $msg;

[Joseph_Sliker]

Okay...I think I am getting that concept (thanks to you all) but the more I think about it, it seems that "Job 1" ought to be turning the password..as it is entered into the login form into something inscrutable before the user ever hits the login(submit) button, so that when it leaves his/her computer, and travels off into the ether it could not be read in any meaningful way by any intercepting/malware programming. (although I suppose it would still be vulnerable to key-capture things that might infect a user's computer).

...This all seems pretty daunting. I guess that's why they pay you real programmer types the big bucks, eh?

[Derokorian]

Joseph Sliker;11011279 wrote:

Okay...I think I am getting that concept (thanks to you all) but the more I think about it, it seems that "Job 1" ought to be turning the password..as it is entered into the login form into something inscrutable before the user ever hits the login(submit) button, so that when it leaves his/her computer, and travels off into the ether it could not be read in any meaningful way by any intercepting/malware programming.

This has never been a concern I've seen visited on any discussion for security, because any transformations you do will have to be in client side script which can be disabled and can also be duplicated as anyone can see client side code. I would recommend focusing on storing it securely and not so much about transferring. Of course that's just my opinion, I could be wrong.

[bradgrafelman]

Joseph Sliker;11011279 wrote:

it seems that "Job 1" ought to be turning the password..as it is entered into the login form into something inscrutable before the user ever hits the login(submit) button, so that when it leaves his/her computer, and travels off into the ether it could not be read in any meaningful way by any intercepting/malware programming.

That has already been addressed by laserlight above:

laserlight;11011191 wrote:

you should be making use of SSL/TLS, otherwise the data submitted is sent in the clear.

[Bonesnap]

laserlight;11011247 wrote:

Since neither MD5 nor SHA1 has been broken with respect to preimage attacks yet (to the best of my knowledge), they are technically still secure if you allow arbitrary length passwords (and use a salt, so collision attacks won't work). Problem is, people don't normally use long passphrases that approach the length of short stories.

Admittedly my knowledge of this sort of stuff is rudimentary. From what I have read, they are mostly considered insecure due to their speed, and due to their "small" hash size so they are more vulnerable to collisions than other algorithms. Just seems like everything I read on this subject is saying to stay away from MD5 and SHA-1.

Also, collision attacks can still work with salts, they're just incredibly rare.

[laserlight]

Bonesnap wrote:

Admittedly my knowledge of this sort of stuff is rudimentary. From what I have read, they are mostly considered insecure due to their speed, and due to their "small" hash size so they are more vulnerable to collisions than other algorithms. Just seems like everything I read on this subject is saying to stay away from MD5 and SHA-1.

Yeah, for the purposes of password hashing, they are insecure due to their speed. It is true that they are more vulnerable to collisions than other algorithms on the basis on hash size alone, but collision attacks aren't really relevant to password hashing, and MD5 is broken for collision attacks anyway. Yes, stay away from MD5 and SHA-1, and if you must use them, use them with key stretching. I'd say the same rule of thumb applies to the SHA-2 family of hash functions too since they are also supposed to be quite fast.

Bonesnap wrote:

Also, collision attacks can still work with salts, they're just incredibly rare.

Well, a collision is very rare in the first place. I think it is more likely that the attacker will get the actual password used from the preimage attack, upon which the salt won't help if the user really did reuse passwords. That said, my use of "collision" is inaccurate since the attacker doesn't know the actual password; it is more like a successful preimage attack that gives the attacker a different preimage, which then can be used as if it were the actual password, if there is no salt.