Secure Login and Page Thesedays

[brianwill76_2016]

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.

[Jacques1]

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.

[brianwill76_2016]

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

[Strider64]

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.

[Jacques1]

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.

[brianwill76_2016]

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.

[brianwill76_2016]

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?

[Jacques1]

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.

[brianwill76_2016]

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

[gizmola]

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.