I can do login realm in PHP and the way that I do it is by setting a session variable and check whether that session variable is set or not. On every restricted page, I check whether a certain session variable is set (or is equal to a certain value). If not, then i will send the user back to the login page. Is this the best way to do it? Is there a more secure way to do it?
This is fine and normal. At the top of the page, you have a header that starts a session and checks whether the user is authenticated. When they're not, make them log in.
A-OK and secure so long as your session IDs are unpredictable, expire quickly enough, and you are using SSL.
If someone can guess your session IDs, they can hijack another user's login.
If you are not using SSL, an attacker can steal the session ID when the client sends it to you.
If your sessions never expire the ID can eventually be guessed.
There's a lot to think about when you're setting up a login system. Here are some questions you want to answer:
Security: You need to encrypt passwords everywhere they are stored (cookies, database, sessions, etc.). How will you do that?
Will users be able to post login to every page? Or will there be a centralized account page?
Is there a remember me feature?
How will users logout?
Do you have activation at your site? How will it work? How will you deal with various scenarios such as unactivated users trying to login?
Will you have login/form redirection? I.e., if a user goes to a page without logging in will you send them there after they login? What if they try to send a form? Will you resend the form.
You have the basic idea right, but the way you structure everything depends on those and other questions.
I've got a similar question on SO before, and here are the answers from security guys.
Put it short, you should think other things like SSL and password hashing, etc...
Hope this helps :)
Related
Currently after successful login I add md5($username) md5($password) in cookies and then every time user browser the site on every page a functions validate these cookies to database. Its working nicely I am happy with it. But is there any thing better i can do?
It good that you are using md5 but PHP also has other option that you can exploit for better security
There is a post here : Login cookies security where i explained in details securing PHP Cookies
You can also see : http://www.phpclasses.org/browse/file/25025.html .. a simple class all you need to do is replace the encryption with a strong one such has RSA or DES
If you nee more information you can just add a comment
Thanks
:)
When an user logins successfully, set a value in $_SESSIONS[]. Then in other pages, just check whether this value is being set in the SESSION array. If set, user is logged in. Otherwise, redirect to the Login page.
If you want to add facility to auto login when user visit your site next time, set cookies. So, when a page is loaded, check if the value in SESSION is set. Otherwise, check the cookies. If the cookies are set with a login signature, directly set the SESSION value. Otherwise, redirect to the Login page.
I think, it is better to use a SHA flavor for hashing than the MD5. If possible, try using SHA-512.
I am trying to understand security when it comes to session cookies in php. I've been reading a lot about it, but I still lack the specifics. I need the basics, someone to show examples.
For example: Do I place session_regenerate_id() before every session cookie? What more shall I think about. I am asking about specifics in code - examples if possible.
Thank you very much.
I am using 4 session cookies after logging in.
SESSION "site_logged_in" = true
SESSION "site_user_nr" = the number of the user to access user_table_nr
SESSION "site_user_id" = the user's id to use when changing data in tables
SESSION "site_user_name" = the name of the user to display on page
When I check if the user has access, I check if all 4 cookies are set, and if site_logged_in is set to true.
Are there better ways? Do I have the completely wrong idea about this? Can users easily be hacked?
In fact you need to have only one session in your website. When you call session_start() session is being created on server and user automatically gets session cookie. Think like session is a some sort of container that placed on the server, you can put whatever you want in that container. However session cookie is just a key to access that container on the server.
It means that you can safely put some data in the $_SESSION and only the user that have cookie with matching session id can read it.
About users being hacked. Yes they can be hacked as long as you don't use HTTPS connection, because cookies and all other data is being transferred in clear text, so if someone intercept users cookie he can access the data stored in the session.
Always use a security token for logging users. This security token could be generated by using crypt(). After logging users in, change the security token periodically until they log out. Also keep the server backup of all the session variables including the security token (in a database). This would also help you to track user login history.
One more personal suggestion: Never use any data from the database as session variables without encrypting it with any of the hashing functions or functions like crypt().
The session information is stored server-side. What you should check is that they're logged in, and that they exists/can log in (in case of deletions/bans).
As you're checking they exist/can log in, you can pull the other information from the database such as name, nr and so on. All you really need is a key called 'logged_in_user' or something that stores the ID of the logged in user. As Alex Amiryan said, the cookie can be copied, so you might also want to store the IP address of the last accessing view in the session, so you can try to ensure security.
I'm using the following code for my user login. Everything works fine but im just wondering the security of using this. I'm using the userid as the sessionid when a user logs in.
What are my security issues with using this?
Can the user change the sessionid to a different number and then be logged in as a different user? (how do i stop this?)
if (!empty($row['member_id']))
{
$_SESSION['id'] = $row['member_id'];
header ("Location: team.php");
exit();
I'm not a security expert by any means.
There was an uproar back in, I want to say, 2010 about session theft. So much so that a group put out a tool called Firesheep that would let you quickly steal other sessions in an open wifi situation. The solution is to protect the entire logged in session with SSL or not be on an open network. Back when SSL was first being used, it proved too slow to be used as a session long security measure, but now computing is fast enough.
TLDR: If you don't SSL, someone can steal your session. Facebook and Google both had the same problem.
For clarification, they can't "steal" sessions so much as they can find out the SESSIONID being passed around in the POST request in order to keep you logged in and then modify their cookies to send that around as you instead. The Firesheep tool could snag Facebook logins in seconds. By modifying the cookie with someone else's SESSIONID, the tool was able to pretend to be the original user, allowing full access to the areas of the account that were unlocked upon login. See also: this.
Another good solution to help things is to reprompt the user during any account sensitive activity regardless of their session. For instance, if they try to change their password or change other account info, make sure to ask for their current password again.
The contents of the $_SESSION server-side are only safe as long as there is no way to submit user data in any way that would eventually end up in the session variable. If someone stole a SESSIONID and then entered data on some form (or if you blindly use the name of the form element as the index into the $_SESSION array) they could get stuff in there. The key is to never ever ever ever ever ever ever ever...EVER....trust what the client side has sent as valid or trustworthy. Paranoia is your friend.
I think you are mixing up the Session ID (SID) with your own login id, you save in $_SESSION['id'].
Your code is fine. Session data is saved on the server and cannot be manipulated by the client directly. So he cannot change the value of $_SESSION['id'] (btw: I suggest to use a more unique key name like 'login_id').
Talking about the real Session ID (SID). The SID is a random string generated by PHP automatically and saved as a cookie on the client’s machine. The client can actually manipulate his SID and so potentially takeover a different session. This is called Session Hijacking and it’s a general problem of using sessions, no special problem of your code. Have a look here for further information: PHP Session Fixation / Hijacking
I'm developing a website in PHP and I'm trying to use OpenID for log-in mechanism. I want a behaviour similar to StackOverflow's. By that, I mean whenever I open stackoverflow, I'm already signed in. I found two related questions on StackOverflow:
OpenId + remember me / staying logged in
Sign in with Twitter, and stay signed in (PHP)
I understand that I should sign in the user and if this is his/her first time, I should sign up the user and set a cookie in his/her system. However what I want to know is what should I store in the cookie? Username/password combination? That seems like a security issue. And the other question is where should I check for the cookie? I would appreciate a simple tutorial/code sample. Thank you.
This is basic web app session management with cookies and OpenID doesn't make a difference here at first.
No, absolutely do not store the username and password in the cookie. Cookies act as "bearer tokens", meaning whoever has the cookie gets in. The best thing to store in a cookie is an unguessable and arbitrary key that you can use to look up real information in a table in your application. So, the user shows up with a cookie of "myappsession" and a value of "234871nb341adf" tied to your domain. Your app would then look up the value of "234871nb341adf" in a local data store and see if it's tied to a valid user. You'd be best served to also check how long ago that user was there and whatnot. If it's a valid session and it's within your time and usage limits, the user is logged in automatically.
For extra paranoia from the RP side, you can make use of the checkid_immediate mode of OpenID to make a background call to see if the user is still logged in to their IdP. If they're not, then you at least know which provider to try to send them to for re-validation and can provide a better user experience.
If you want your site to be really secure, you should do all of your sessions over HTTPS and tag your cookies as both "Secure" and "HTTPOnly", which is documented on the setcookie function manual page: http://php.net/manual/en/function.setcookie.php
Hey guys, I was scanning my site for security and I noticed that it was possible for non users to send requests and post information, so I decided to put login checks on all information posts. I was wondering if it was a good way to keep a session id that is created by md5(uniqid()); in a session variable $_SESSION['id']=md5(uniqid()); for each user and then store that in a database under active users for that user. Then when a user tries to insert information, verify that their $_SESSION['id'] variable is equal to the one in the database where the username equals their $_SESSION['username']. What are your ideas on this guys? Thanks in advance!
One solution would be to set a session variable called "loggedin" or something when the user logs in, and make sure that variable is set when you do the database updating (call session_start() before doing the SQL calls, and check the variable in $_SESSION before you send the queries). That way, non-logged in users can't update the database, unless they steal a session from a user already logged in. From what I understand of the problem, this sounds like the simplest solution.
It sounds to me like the solution you came up with is already built into PHP sessions with SESSIONID. A new session in PHP automatically generates a random string identifying your session from the sessions of others. I could be misunderstanding, though.
Why not to just check if $_SESSION['username'] is set?
I've done this before on sites, but it's less of a security measure than it is a feature to allow users to have multiple concurrent sessions. The real key is to check for a valid login token whenever you're performing an operation that requires authorization, and to run your site over HTTPS so that the session cookie can't be hijacked.