Currently a friend of mine and myself are working on a site together. We have our login system down, but are using sessions. I, myself, have always used cookies for logins, though my friend prefers sessions.
I keep telling him we should have two or more sessions we can compare with the database to make sure it's the accurate user, and not someone who somehow scammed the ID.
For example:
$_SESSION['id'] = $YourId;
$_SESSION['salt'] = $SomethingElseTheDatabaseHas;
This making it more secure instead of just one session that the database can compare with.
Using multiple session variable to store information does nothing for security since the session data is stored server-side. The only thing that the client knows about the session is the session ID that it stores in a cookie. The server uses the session id to lookup data for the user. If you're using a hash stored in a cookie to identify users, you might as well use sessions since that basically does the same thing, but makes working with a user's data much easier.
I'm not sure exactly what you mean by using cookies to store the data, but if you mean that the client would have a cookie with their user id that the server uses for authentication, you should rewrite that immediately since it basically allows the user to be whomever they want.
Related
So I recently made the decision to use Session ID's for authentication on my website instead of JWT's, so I'm still trying to play catch up a little bit here.
I guess my concern is pretty simple. If I'm going to have my database handle my sessions that are currently active for the users that are logged in (probably through a table that has a column with the UserID and the SessionID) how can I use PHP to generate a completely random Session ID? I will then pass that Session ID into a httpOnly cookie.
I assume this will work with my Angular front-end as I can use the withCredentials boolean option on every http request since I won't have direct access to the Session ID cookie.
So when a user wants to access a restricted area, their http request will contain the Session ID cookie and my PHP will determine what their User ID is by doing a lookup on the CurrentSession table. This will then allow PHP to determine the user's access level.
All this will be done over a HTTPS connection but I think I will still have to worry about CSRF attacks so I will probably use the Double Submit Cookie method as Angular already provides support for it.
So I guess my main question is, would simply finding out a way to generate a unique Session ID with PHP work for securing my app? Or would somehow encrypting the Session ID so only my PHP can decrypt it be a good idea, so in case somehow an attacker got access to the Session ID from the cookie, it would solely be an encrypted version of it, so it would be useless.
I would suggest using PHP's session_start() which will handle the session in its entirety including any cookies that need to be written to maintain the session depending on your particular connection at the time.
All you need to do is put this at the very top of your PHP scripts:
<?php
session_start();
A PHP constant "SID" should be available to get your session id which you could store in MySQL for other purposes if you wanted to - but it may not be necessary. You can also use session_id() as well.
I need to build my own system for part of a computer security project without using php sessions (just cookies) and im just lost. All the tutorials ive found use sessions (for good reason) so I was wondering if anyone knew of a roll your own php user authentication tutorial.
You could basically implement something session like yourself.
This would include the following tasks:
generate a random session id for new users (or on login - based on the exact use...)
save it into a cookie
do save additional session inforamtion somewhere on the server together with the session id (e.g. in a database table)
on subsequent page accesses check the session id in the cookie versus the data on the webserver to identify users and grant access
However it should be mentioned that a cookie only based solution is never that good. If a client for example doesn't have cookies enabled it won't work at all. A possible solution for this is to send the session id as GET parameter with every internal link if cookies are not enabled.
Sessions would make it much easier. That being said, where are you getting stuck mate?
To get started using Cookies in PHP, check this out: http://www.w3schools.com/php/php_cookies.asp
You could either
implement your own Session handling as s1lence suggests (which might be exactly what the professor wants you to do) or
implement your own Session handling through appending the session id to the QueryString (making it work for non-cookie browsers) or
you could store the user/password pair in cookies (which would force you to reauthenticate the user for every request)
I wouldn't recommend the latter, but if it's all about avoiding the Session Mechanism it's an option I guess. And a last remark, if this doesn't have something to do with understanding why Session is important you should really question your teachers task.. ;)
You should not use cookie for such system in cause cookie are stored on the client side. And any one can change it. Sessions are stored on the server side and only you can change it (also other system users can change it if they have directory access or db access if you store sessions in db). If you strongly need to use cookie you can encrypt login/password can write to cookie, but the using of sessions is more safely.
While creating my website i was stuck on a thing.
Wether i should use $_COOKIE or the session.
I thought using using $_COOKIE would be better.
But what should i store in cookie the users username or the user's unique id ?
And how much time forward i should put the time of the cookie ?
And should i forward the same time on each page or different ? If different then how much ?
It ultimately comes down to whether your website/application needs to be stateless or not. (See Webservices are stateless?). Its mostly a design decision, but I prefer stateless applications where possible.
If you do use cookies here are some tips:
You want to store data in the cookie that will uniquely identify the user, but something that is not able to be guessed.
It is common to put a user_id or a username (provided the user is unable to change it) and a random hash stored alongside the row in the database. When it comes to logging a user in load the user by their user_id and check that the hash in the cookie matches the one in the database.
As far as how long to store it for, that depends on the nature of your application. If it contains sensitive information then its probably not a good idea to make it last for a long time. You should update the time each time the users requests a page so if a user is using the site they will remain logged in for the duration of their visit.
It is really important not to put sensitive information in cookies, because they are stored in plain text on the user's computer.
You've not provided any information relating to the reasons for your choice of data substrate nor any indication of what you are trying to achieve ("php optimising members after login" - is meaningless gobbeldy-gook).
Wether i should use $_COOKIE or the session.
Hopw much data are you trying to store? For how long? Do you require to have access in the absence of a session? If so does the data need to be available? What is the impact of the user changing the data outwith your website?
But what should i store in cookie the users username or the user's unique id ?
Neither - if your site believes the assertion in the cookies, then hacking your site is as simple as changing the cookie value.
I'm trying to figure out if it is better to store my user's data in a session cookie (like password, username, etc), and update that cookie only when I change the MYSQL database from my PHP,
OR
Store the user's username and user ID in a session cookie and reach out to the MYSQL database every time I need to get the user's data.
Which one is the better method..? I've never actually set up a login system so any advice would be much appreciated.
A session and a cookie aren't the same. A session simply stores its session ID in a cookie (client-side) and all the session data on the server. I presume you really meant session where you used the word 'cookie'.
Moving ahead to answer your actual question, it's perfectly fine and safe to store most user details in the session. You should never need to store the password in a session though, since you use it only for authentication. Apart from that, it's ideal to cache frequently used user data (things that you may display on every page) in your session to save trips to the DB.
The concern that Chris mentioned - changes to user data - is almost non-existent, because user data will (should) not be modified by anyone except the user himself, in which case you can update the session along with the DB.
Good question. I've kept the user data in the PHP session. Since that's all server side it should be safe to do so, and avoids an extra database lookup.
The downside is that you won't automatically pick-up changes to the database that happen during that session... but user data isn't normally so dynamic that I'd care.
You shouldn't store a password in a cookie. I would store the details in the DB and use memcached to reduce the load on the DB.
ive heard a few timse that sessions need to be cleaned with mysql_real_escape_string or htmlspecial chars because they can be modified. what im wondering is how are they modified because when i look at a websites session named PHPSESSID the value it contains is always encrypted.
first of all what encryption method is it using and how is it modified. the reason i want to know this is to better understand how to secure myself based on what methods people are using out there to high-jack sessions
thanks.
They cannot be modified, they're stored on the server. The PHPSESSID is just an identifier, it's not encrypted but randomly generated (so it's unique to each user). People hijack sessions by stealing the PHPSESSID cookie, usually through a cross site scripting attack. Read the answer to this for a nice summary of sessions in php - What do i need to store in the php session when user logged in
Sessions are stored on the server. That means all data is stored in temporary files and are deleted after an x amount of time. The browser does not store session data. It stores an ID of the session, which the server uses to get the right temporary file.
So the user never actually has access to variables stored in a session. But has a reference to their session. It is possible to get someone else's session ID. This way you can pretend to be another user. If sessions are used for validation.
Read up on session hijacking here.
The thing that can get modified is the session id send to you by the client. So, as with all user supplied data, this needs to be 'cleaned' before you use it anywhere, like for example with mysql_real_escape_string before inserting it into a MySQL database.