HTTPS for login

Is https good enough for passwords

[typomaniac]

Please excuse my ignorance around this question but I know that https is used for sites which handle credit cards, etc., but what I'm wondering is https good enough for a login system? I've never had much reason to concern over such things but I'm putting something together in a php script, I'm fairly new at this one but I searched out secure login systems for php and everything talks about salt & hashing, etc.,. If I use https, which is included for free with the host, doesn't use the domain name but the username.webhost's name in the url which is okay also but I'm just wondering if that is an okay way of doing a login. I guess what I'm really trying to say is I don't know much about encrypting, salt, hashes and all and if I can get out of all that by using https thats good by me. Thanx and have a great day.

[keyplyr]

https good enough for a login system?

Yes

You'll want to test the certificate strength. Here's a tool [ssllabs.com]

[typomaniac]

Looks okay, I think. I just checked it an the following was ssllabs report:
No known issues
and as far as limitatons go:
SSL Labs currently shows only one certificate, even with servers that have more than one. This is a limitation of the UI, which shows the first encountered certificate. Internally, SSL Labs collects all certificates. All will be shown in a future release.
In general, cipher suite support is done using only the best-supported server protocol. This means that SSL Labs might not show all supported suites when used against servers that enable different cipher suites depending on the best protocol version offered by the client. In practice, SSL Labs has additional tests for BEAST (done with SSL 3 and TLS 1) and obsolete suites (done with the oldest supported protocol except SSL 2); this means that it will catch all suites in the majority of cases. A future SSL Labs version will test cipher suites separately for each supported protocol.
Should do okay as the site I'm logging to does not control the International Space Station, lol, Thanks much!

[graeme_p]

Yes and no, it will secure the transmission of the password from the browser to the server, but that is not enough. You should not store passwords as plain text, you should store a salted hash.

You should be very careful about designing your own authentication system. Much better to use a well tested one. This is one reason I prefer to use frameworks.

[robzilla]

Salts and hashes relate to how you store the passwords locally, e.g. in a database, whereas HTTPS "only" encrypts data traveling over the wire between your user and your server. It's possible (but pretty much impossible to know) that someone is listening in on that traffic, and when your user enters his/her password into a form field and submits, the password is right right there for anyone to sniff out unless encrypted. If you only use HTTPS for the log-in form, and HTTP for whatever happens after, you're still at risk because session cookies that keep a user logged in will be openly visible and vulnerable to theft and manipulation. So, ideally, everything after log-in should be HTTPS, too, but it isn't really acceptable that your domain changes for that, so I would ask your host if you can have a certificate specifically for your domain.

Hashing a password before storing it ensures that anyone who gains access to your database of passwords cannot use them, because it's near impossible to find out what the original password was based on the hash string. A popular framework for password hashing is phpass.

[bhukkel]

A little offtopic but phpass is outdated:

At this time, if your new project can afford to require PHP 5.5+, which it should, please use PHP's native password_hash() / password_verify() API instead of phpass

[openwall.com...]

[NickMNS]

Just to add to robzilla's answer. Salting is used to randomize the hash functions used to hash the password. If all the passwords in your system were hashed with the same hash function then any two identical passwords would have the same hash value. Hackers could then use this to break the hash with a lookup table.

[robzilla]

A little offtopic but phpass is outdated

Oops! Good to know, thanks. It's been a while since I coded anything with hashing.

[TorontoBoy]

Are you writing a site from scratch using php? Most packages and frameworks should come with a robust login system already.

Playing with hashing and salts is not trivial. Code it incorrectly and there's a security hole. There are many evil geniuses out there that like the challenge.

[typomaniac]

If I begin with the form in https then everything linked to it in any way shape or form will be https so no problem there. I intend to demand that sending links verify as https also. In the future I plan to get a certificate for the domain only but for now I have to deal with what I have to work with. It will only take a little bit of changing on a bunch of links at that time but with search & replace that should be as easy as throwing snowballs. I’ll look into password_hash() / password_verify() for salting things up. I always kept the passwords hashed&re-hashed before but getting the word to the server is my main concern here. Nothing much I can do if someone is listening in on me but no money is involved with the communications and nothing of a national security interest, but I do like privacy. Thanks to all for the input---all will be taken into consideration.

[NickMNS]

Nothing much I can do if someone is listening in on me but no money is involved with the communications and nothing of a national security interest, but I do like privacy.

The "I have nothing to hide" argument rings a little thin in my view, specially in this case.

When users create an account on your website, they put trust in you to keep their information safe. Knowingly implementing weak security system is wrong. A site may not handle financial transaction or store confidential personal information but should hackers be able to hack you site and gain access username password pairs. The first thing these hackers will do is attempt to log on to various other sites that do hold such sensitive information. Clearly user's should know better not to use the same username and password on multiple sites, but many don't know this or simply neglect to do it.

Now you may say, that is the user's problem. Not only. If you're site is using un-salted passwords. The fact that hackers know many username password pairs will allow the hackers to break the hashing of other unprotected sites more quickly. This is similar to immunization, if everyone in a population is vaccinated one can eliminate the threat. If many people are vaccinated, but a few are not, then those few are protected to a large extent by the many. But at some point a tipping point is reached where the many are not sufficient to protect the few at which point the few become vulnerable without realizing it.

In my opinion we as webmasters have responsibility to protect our websites for the greater good.

[typomaniac]

I've put much thought into what you have said and have looked up lots of info on hashing and salting, etc., and am finding lots of info but nothing which really explains, using examples how it should be done. Do you know of any sights that might have an easy to follow tutorial on the subject? I'm not looking to re-inventing any wheels or anything, just a straight out example to go by. Maybe in time I can make mods but that won't be for a while.

[typomaniac]

What I have found so far is:

$password='changeme';
$options = [
 //'salt' => uniqid(mt_rand(), true) //write your own code to generate a suitable salt
 'cost' => 12 // the default cost is 10
];
$hash = password_hash($password, PASSWORD_DEFAULT, $options);
echo"$hash ";

if (password_verify($password, $hash)) {
 echo" Success!";
}
else {
 echo" Invalid credentials ";
}

Am wondering if this would be a good way to hash p-words. I couldn't get anything to work with the salt functions. I found this at:
[sitepoint.com...] I managed to get through everything else in the script but am really scratching my head on this one. Like I said, there is no money going back and forth but after reading about how careless people are with passwords and all it has me really thinking. I've seen all kinds of functions posted but not sure how to make them work but these lines did.

[robzilla]

Your choice of PASSWORD_DEFAULT as the hashing algorithm does not support any options. Only PASSWORD_BCRYPT allows you to set 'salt' and 'cost'. There's no need to set the salt yourself, though, because the password_hash() function automatically does that for you. The default cost is 10 which is sufficient for most. So you can just remove $options and use password_hash($password, PASSWORD_DEFAULT).

It's always a good idea to read the PHP documentation for a function: password_hash() [php.net]

[typomaniac]

Yup ! One of the first things you see on that page is

Warning The salt option has been deprecated as of PHP 7.0.0. It is now preferred to simply use the salt that is generated by default.

Maybe its just all this stuff I've seen about salt lately. I guess its not as hard as I'm making it to be. I appreciate your post robzilla, Life just became muh less confusing.
Thanx much !