mds1256 Posted April 20, 2012 Share Posted April 20, 2012 Hi I am developing a system that users can log into. Couple of questions: 1. Should I use SSL for when users submit the login form e.g. post to https just for login? 2. Is putting the https address in the form action enough to encrypt the login details or does the page that you are entering the details on (e.g. the login form webpage) also need to be encrypted? Thanks Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/ Share on other sites More sharing options...
trq Posted April 20, 2012 Share Posted April 20, 2012 IMO you should use https on *all* pages. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339051 Share on other sites More sharing options...
mds1256 Posted April 20, 2012 Author Share Posted April 20, 2012 IMO you should use https on *all* pages. But doesnt that increase server load? And really the only sensitive information is the username and password being posted in clear text. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339053 Share on other sites More sharing options...
trq Posted April 20, 2012 Share Posted April 20, 2012 Look at any of the big sites. Facebook, Twitter they all use https for all pages. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339058 Share on other sites More sharing options...
mds1256 Posted April 20, 2012 Author Share Posted April 20, 2012 Look at any of the big sites. Facebook, Twitter they all use https for all pages. They also have huge farms of powerful servers lol, but yes I take your point. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339060 Share on other sites More sharing options...
kicken Posted April 20, 2012 Share Posted April 20, 2012 To provide a few more specific answers (though I agree with thorpe in that enabling SSL for all is good): 1. Should I use SSL for when users submit the login form e.g. post to https just for login? Yes, you should at minimum use SSL when posting the login information to ensure it is encrypted. 2. Is putting the https address in the form action enough to encrypt the login details or does the page that you are entering the details on (e.g. the login form webpage) also need to be encrypted? Setting the action to an https url is technically enough, as that will cause the post itself to be encrypted. You should serve the login page itself over https as well though so that the browser includes a visual indication that the page is encrypted. That helps users feel safer if they can see the SSL signs before entering their details. Encrypting the login page itself can help prevent man-in-the-middle attacks as well. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339062 Share on other sites More sharing options...
PFMaBiSmAd Posted April 20, 2012 Share Posted April 20, 2012 After you have logged in, the sensitive information is now the session id that you are sending from the client to the server on every http request. If someone 'was' monitoring the data packets (which is why you would be using SSL in the first place), such as over an unencrypted wifi connection, they would have the session id and can visit the site as you and do anything you can do after you have logged in (which is why you typically re-authenticate when doing critical things, such as modifying profile information, making purchases,...). Since they already have access to the same network you are using, they will also have the same IP that you have when they visit the site. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339064 Share on other sites More sharing options...
mds1256 Posted April 20, 2012 Author Share Posted April 20, 2012 After you have logged in, the sensitive information is now the session id that you are sending from the client to the server on every http request. If someone 'was' monitoring the data packets (which is why you would be using SSL in the first place), such as over an unencrypted wifi connection, they would have the session id and can visit the site as you and do anything you can do after you have logged in. Since they already have access to the same network you are using, they will also have the same IP that you have when they visit the site. Have kind of thought about that one and I regenerage the session ID after so many page requests to get a new ID. So on another note what is the best way to divert my site to https if a http is entered, I am using IIS for this, is there an easy way of doing this that will prevent users from visiting the http version. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339066 Share on other sites More sharing options...
xyph Posted April 20, 2012 Share Posted April 20, 2012 After you have logged in, the sensitive information is now the session id that you are sending from the client to the server on every http request. If someone 'was' monitoring the data packets (which is why you would be using SSL in the first place), such as over an unencrypted wifi connection, they would have the session id and can visit the site as you and do anything you can do after you have logged in (which is why you typically re-authenticate when doing critical things, such as modifying profile information, making purchases,...). Since they already have access to the same network you are using, they will also have the same IP that you have when they visit the site. A token in plan text is a lot less worrisome than a password, IMO. If a user logs out, the token is destroyed. Some sites will even regenerate the token per-request when a user is logged-in. That's not to say your post isn't sound advice. Link to comment https://forums.phpfreaks.com/topic/261313-ssl-use-for-login-or-not/#findComment-1339092 Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.