This is a multi-part question, so feel free to give input on any one of the parts, but since I can only accept one answer, I will accept the most complete answer in relation to all that is being asked. I will upvote partial answers if they are relevant and useful.
First, a little background, without going TL;DR on the question: I am using Quake Framework (yes, it's mine) for this project - to quickly describe it, it uses CodeIgniter and jQuery 1.8.0 mainly (among others, but they are irrelevant for the question.) It also includes the Total Storage jQuery plugin (for local storage) and jQuery Cookies as a fallback for browsers that don't support local storage.
Part 1:
I have built a user authentication system. The login has a "remember me" feature (which is not yet functional) - what is the best way to store the user's data? Some thoughts:
Store the username and sha1'd password in local storage/cookie. This seems to me to be a possibly insecure option, but I'm unsure.
Store some kind of hash (maybe PHP's com_create_guid()?) in the localstorage/cookie as well as in the database (maybe along with a date for expiry?)
Part 2:
After implementation of the "remember me" feature, what is the best way to finish implementing it? Should I have every page check for the cookie (because the user could initially hit any page and would need re-logged?) While each page of course needs to check the session, and once they are re-logged by the cookie/local storage, they will get a regular session, it seems very redundant to check for both a session and a cookie on each page (we'd of course first check for a session so that we don't check cookies of logged-in users repeatedly, and then check for the cookie if there's no session, but still.) Is there a better way?
Part 1
It would be best to generate a random token(hash you mentioned) in the server, and save it both in the DB and cookie. Making it random will prevent others from "guessing" or generating your token. Using a GUID would be your best option.
Part 2
In each page, you can check if a session exists. If no session is available, check for your auth cookie. If auth cookie is available, trigger your auth-check code. That way, you only need to check the auth cookie when user is not logged in already.
Related
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.
I usually hang out in a community that uses a bulletin board software.
I was looking at what this software saves as cookie in my browser.
As you can see it saves 6 cookies. Amongst them, what I consider to be important for authentification are:
ngisessionhash: hash of the current session
ngipassword: hash (not the plain password probably) of the password
ngiuserid: user's id
Those are my assumptions of course. I don't know for sure if ngilastactivity and ngilastvisit are used for the same reason.
My question is: why use all these cookie for authentication? My guess would be that maybe generating a session hash would be to easy so using the hashedpassword and userid adds security but what about cookie spoofing? I'm basically leaving on the client all fundamental informations.
What do you think?
UPDATE #1
The contents of these cookies are what I think they contains. I'm not sure about it.
Of course if call a cookie ngivbpassword and contains an hash, my guess is hashedpassword. Probably it could be password+salt.
My main concern is about these solution giving to much information when under a cookie spoofing attack.
UPDATE #2
This question doesn't want to criticize the way these specific software works but, thorugh these answers I want just to learn more about securing software in a web environment.
This happens because session and login cookies may have different lifecycles.
Imagine website with millions of users every day. The website won't store your session for a year just to log you back the next time you get back.
They use login cookies for that.
These cookies are also called Remember-Me cookies.
Sessions are not persistent. Cookies are.
Update #1: I haven't worked with vBullettin but it looks like the classical "Remember me" feature.
Update #2:
Yeah, it's a remember me feature, I'm
asking why they're doing it in that
way
Alright... How do you implement a "Remember me" feature? You obviously need to use cookies, I assume that's clear. Now, what do you store?
The naivest way is to store user and password in clear text and perform regular authentication. It's among the most insecure mechanisms you can use yet some sites actually do it that way.
Second slightly less naive way is to store a hash of the user and password and perform a modified version of the regular authentication. Is not as bad as the previous method but it still suffers from some issues; for instance, there's no effective way to disable or expire a saved cookie from the server.
Third way is to keep a database table with "remembered" sessions, identify each one with a long unique string and store such string in the cookie. The string can be random or calculated but, of course, randomness has the advantage that the string cannot be guessed even if you know the algorithm.
Further security can be accomplishes by storing dates, IP addresses and other piece of data in the server.
As I said, I know nothing about vBulleting but it seems they're using method 2 or method 3.
Update #3:
The contents of these cookies are what
I think they contains. I'm not sure
about it. Of course if call a cookie
ngivbpassword and contains an hash, my
guess is hashedpassword. Probably it
could be password+salt.[...] My main
concern is about these solution giving
to much information when under a
cookie spoofing attack.
A successfully cookie spoofing allows you to fully impersonate the user so you can just enter the control panel and enjoy the free buffet, thus making the cookie content irrelevant.
Whether they store a salted password or it's just a name it's something I don't know.
Here is a question, what are your concerns? Are you building some kind of authentication system?
I also think that having the user id and password in cookies can be a security issue.
is user id encoded or an integer?
Cookies should be as-small-as-they-can peace of information about who you are on the server.
Sessionhash, session_id or sid is unique ID of you (your session on the server). The rest of cookies can be easily hidden on the server side.
Holding password hash in cookies is a security issue. You should avoid that.
Last 4 cookies comes from google ads.
PS. Most bulletin boards are not so great software anyway.
Currently I autheticatic user sessions by matching a key in the session to the same key in a MySQl database. I regenerate the session with a random number that is MD5 protected on every page load. I am aware that sessions are not inherently secure and I'm looking for further security options that can be attached to this method in a speedy manner.
Any Ideas?
Since the session data is stored on the server side and the session ID is used to associate a client’s request with a certain session, it’s the session ID that needs to be protected. And the only viable measure to protect that session ID is to encrypt the connection between the client and server using TLS/SSL.
So you can use sessions as long as the data transfer between client and use is secured. Additionally, you can fix the PHP session to the TLS/SSL session so that the PHP session is only usable within that specific TLS/SSL session.
You're already jumping through hoops which do nothing to enhance the security, and potentially compromise the functionality of your site.
I autheticatic [sic] user sessions by matching a key in the session to the same key in a MySQl database
Even leaving aside the spelling mistakes, this is nonsense. Do you mean you authenticate requests by this method? If so, it's still not helping your security. You've already authenticated the request by de-referencing the session. Whether the request is authorized is completely different - if you need to authenticate the user then you should flag this in the session data.
It sounds like you're trying to prevent a CSRF, but getting this all mixed up with whether you're authenticating a user, a session or a request.
I regenerate the session...on every page load
Again, this is semantic nonsense. You can't "regenerate the session". Do you mean you create a new sessionId? If so then all you are achieving is creating errors when users try to open a second window or use the back button. It provides very little CSRF protection.
is MD5 protected
Just using random cryptographic functions doesn't make your application secure. It doesn't matter what the mapping between the real data and a surrogate identifier is, on its own it provides no protection against MITM.
Either you've done a very bad job describing your current security measures, or you've written lots of code which serves no useful purpose.
Go and read a lot of Stefan Esser's and/or Chriss Schiflet's stuff.
When a user logins I get him/her's ID and save it in a session var. What I wonder is, is this the way to go? Or should I use cookies? so it automatically login and so on.
session_start();
ifcorrectlogin {
$_SESSION['id'] = mysql_result($loginQuery, 0, 'user_id');
}
how do you authenticate your users?
//Newbie
Yes, this is the way to go. The session itself is already backed by a cookie to remove you any programming efforts around that. The session (actually, the cookie) will live as long as the user has the browser instance open or until the session times out at the server side because the user didn't visit the site for a certain time (usually around 30 minutes).
On login, just put the obtained User in the $_SESSION. On every request on the restricted pages you just check if the logged-in User is available in the $_SESSION and handle the request accordingly, i.e. continue with it or redirect to a login or error page. On logout, just remove the User from the $_SESSION.
If you want to add a Remember me on this computer option, then you'll need to add another cookie yourself which lives longer than the session. You only need to ensure that you generate a long, unique and hard-to-guess value for the cookie, otherwise it's too easy to hack. Look how PHP did it by checking the cookie with the name phpsessionid in your webbrowser.
Cookies can be manipulated very easily. Manage login/logout with Sessions. If you want, you can store the users emailaddress/username in a cookie, and fill the username box for them the next time they visit after the present session has expired.
I would try to find a session engine so you don't have to deal with the misc. security issues that bite you in the ass if you do the slightest thing wrong. I use django which has a session engine built in. I'm not aware of the other offerings in the field although I would assume most frameworks would have one.
The way they did it in django was by placing a cryptographic hash in the user's cookies that gets updated every page view and saving all other session information in a database on your server to prevent user tampering and security issues.
As BalusC mentions, the session_-functions in php are the way to go, your basic idea is sound. But there are still many different realisations, some of them have their pitfalls.
For example, as Jonathan Samson explains, using cookies can result in security holes.
My PHP is a bit rusty, but I remember that the session_-functions can also use session IDs that are encoded in URLs. (There was also an option to have this automatically added to all local links (as GET) and form targets (as POST). But that was not without risks, either.) One way to prevent session hijacking by copying the SID is to remember the IP address and compare it for any request that comes with a valid session ID to to IP that sent this request.
As you can see, the underlying method is only the start, there are many more things to consider. The recommendation by SapphireSun is therefore something to be considered: By using a well tested library, you can gain a good level of security, without using valuable development time for developing your own session system. I would recommend this approach for any system that you want to deploy in the real world.
OTOH, if you want to learn about PHP sessions and security issues, you should definitely do it yourself, if only to understand how not to do it ;-)
I'm looking for tips and ideas on how to best incorporate authentication with PHP using Cookies.
Should each php script check for the cookie value to determine if the user is still logged in? Should there be one script that does this check and Include that script from each of the other scripts? Can the cookie value be seen by php from different depths of the filesystem?
Like: blahblahblah.com/ and blahblahblah.com/login/
Can they both read the cookie?
Lots of questions on one post, but thanks!
nothing is safe on the client side.
You change the login flag on Cookies easily on any browser. Thus it is more recommended to be saving login-related data on php's $_SESSION
If you wish to extend the session, simply look at session_set_cookie_params().
By default, the same session will be used for the current domain and all the paths on that domain. Thus it is readable for both blahblahblah.com/ and blahblahblah.com/login/
When the user logs in, save the username and the hash of the password in the Session.
At the start of each script, verify the Session's username and password with the one in database. If is correct, then set a flag (e.g. $userLoggedIn = true) to indicate on server-side that the user is logged in. else false.
Some thoughts, in no particular order:
Separate out the various layers: persistent storage vs authentication.
PHP sessions are quite robust and are the recommended way to maintain persistent storage.
You can have a valid session, but not a valid login.
Avoid multiple cookies. One is enough. PHP sessions work with one cookie.
You can set sub-domains and paths on cookies, but there's really little point unless you set lots, which is not recommended (see above).
Put everything you think you might want in a cookie in the session instead.
You should have some common code that all your pages include. That is where you initialize your session. Then everything will Just Work. It can also verify the login is valid, too.
Have one place that does the login authentication and everything associated with that.
Don't forget a logout screen!
Its a good idea to have one script do the session/login check and include it in the secure pages. AS for the depth , you can define that in the setcookie() if the directory parameter is set to "/" then its accessible all across.
Generally its a good idea to use sessions instead of cookies , as thats more secure , but you can decide to build your own session system based on encrypted data in the cookie and that can work too , but again sessions, which store data on the server side are recommended.
The cookie is per domain, so no matter how deep you are in your directory structure, the cookie will be read OK (as long as your domain stays the same - NB this means that www.example.com and example.com can be different cookies).
I'd suggest having an authentication check that compares the session ID in the cookie with eg a database table listing logged in users and their session ID - this check can be in its own method/include file that is include()'d on each page. That way the check will be performed on every page load. NB this is basic and there are much more secure methods - some of which have been mentioned in other comments here.
As Mauris said though, nothing is safe on the client side - don't use a cookie to store a "logged_in" value which you check for true/false!