brianwill76_2016 Posted June 15, 2017 Share Posted June 15, 2017 Hi I need to setup a secure php login form that takes you to a secure index page with 2 buttons which when clicked pull data associated with that user into a page using jQuery GET, the request the jQuery makes is to a PHP page which does a SELECT lookup I have an understanding of PHP, but we recently upgraded to PHP7, and i'm wondering what people consider the best method to secure a page and request data via jQuery GET. Is it still best to set and use SESSIONS to secure pages, and maybe have a unique hashed SHA1 code attached to the user record for the PHP scrip to use when doing the jQuery GET request I thought of maybe also using IP Address to secure, but the user might be hopping onto another network during the session. Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted June 15, 2017 Share Posted June 15, 2017 User authentication hasn't changed in the last ~10 years. We still use HTTPS to protect the communication, hash the passwords with bcrypt and implement sessions with, well, sessions. I don't know what you mean by “unique SHA-1 code” -- except that SHA-1 is ancient and one of the most abused algorithms in security. Doing stuff with IP addresses doesn't make a lot of sense either, because IP addresses are shared, reused and changed all the time. Quote Link to comment Share on other sites More sharing options...
brianwill76_2016 Posted June 25, 2017 Author Share Posted June 25, 2017 User authentication hasn't changed in the last ~10 years. We still use HTTPS to protect the communication, hash the passwords with bcrypt and implement sessions with, well, sessions. I don't know what you mean by “unique SHA-1 code” -- except that SHA-1 is ancient and one of the most abused algorithms in security. Doing stuff with IP addresses doesn't make a lot of sense either, because IP addresses are shared, reused and changed all the time. Thanks. If I store a unique value (ie: 3c183a30cf) with every users db record, then use that value in a session when pulling the users data, is it worth changing that unique value everytime a login is done, to stop is being used by an attack in the future? Or maybe changing it every time they visit a protected page. I don't imagine updating that value would have a huge impact on server load. Or is that all a waste of time and I should just store the user db record ID as the session value? thanks Quote Link to comment Share on other sites More sharing options...
Strider64 Posted June 25, 2017 Share Posted June 25, 2017 I'm in the process of redoing my login scripts to add better security and I will eventually post it on my Github account (https://github.com/Strider64) as a repository once I have it working. With that said I would check into password_hash() http://php.net/manual/en/function.password-hash.php and password_verify http://php.net/manual/en/function.password-verify.php this takes care of encryption and salting for you. Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted June 25, 2017 Share Posted June 25, 2017 I store a unique value (ie: 3c183a30cf) with every users db record, then use that value in a session when pulling the users data For what purpose? Or is that all a waste of time and I should just store the user db record ID as the session value? Sounds like it. Quote Link to comment Share on other sites More sharing options...
brianwill76_2016 Posted June 25, 2017 Author Share Posted June 25, 2017 For what purpose? Sounds like it. I'm under the impression that sessions can be spoofed, so would storing the user ID as the session not be a bad idea, as people could spoof an user ID value and gain access to data? My thought was to store a unique random code with each user record, and store that as the session value So when doing a SELECT or UPDATE etc, I can reference the user record with that unique code. Quote Link to comment Share on other sites More sharing options...
brianwill76_2016 Posted June 25, 2017 Author Share Posted June 25, 2017 I'm in the process of redoing my login scripts to add better security and I will eventually post it on my Github account (https://github.com/Strider64) as a repository once I have it working. With that said I would check into password_hash() http://php.net/manual/en/function.password-hash.php and password_verify http://php.net/manual/en/function.password-verify.php this takes care of encryption and salting for you. How did you handle access to secure pages? Did you use a method of session checking? Quote Link to comment Share on other sites More sharing options...
Solution Jacques1 Posted June 25, 2017 Solution Share Posted June 25, 2017 I'm under the impression that sessions can be spoofed, so would storing the user ID as the session not be a bad idea, as people could spoof an user ID value and gain access to data? I don't think you understand how sessions work. Sessions are stored server-side, usually as files. Users cannot access those files, let alone change them. Maybe you're confusing sessions and cookies. Of course there are attacks against sessions, but none of them is prevented by your random IDs. So the approach is just useless. Quote Link to comment Share on other sites More sharing options...
brianwill76_2016 Posted June 27, 2017 Author Share Posted June 27, 2017 I don't think you understand how sessions work. Sessions are stored server-side, usually as files. Users cannot access those files, let alone change them. Maybe you're confusing sessions and cookies. Of course there are attacks against sessions, but none of them is prevented by your random IDs. So the approach is just useless. Thanks for the advice Quote Link to comment Share on other sites More sharing options...
gizmola Posted June 27, 2017 Share Posted June 27, 2017 Just for the record, php sessions work by setting a cookie with a session id that by default is a random value hashed. The importance of that is that it should be hard for a person to "guess" a valid current session id. If a person can sniff network traffic (think your local coffee house or college LAN) they can see this ID in the http header data. With a session ID I can now impersonate you by manually setting a cookie in my browser. At that point, the server will think I am you. There is also something called "session fixation" I won't go into, but is also an exploit vector for some apps. The reason I bring this up, is that there is no alternative to https:// for your apps w/sessions. If you don't utilize https, you will always be vulnerable to impersonation via stolen session id. There are still good practices (regeneration of session id on any change to account information or escalation of privilege) but you still need https. At no time however, does this expose session variables, although your code is going to permit the exposure of whatever data it allows through your application code. I hope this helps clarify some of the confusion expressed in the initial questions. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.