I use the Yii framework, and I notice that when a user logs in his connection is saved inside a session.
What that means is if someone would guess someone's else session id, he could log in inside his account.
So I wanted to know if I should to keep it that way and should not change anything because it's secure enough, or will it be better to make some other authentication system? For example, storing the user's id and token inside a cookie.
Related
I am currently developing a back-end for an iOS application with Apache, PHP and MySQL. However, I am a bit lost now that I have to implement an authentication method into the application.
Whenever a user signs up to the application, a unique user id is issued and saved in the database.
Then, when the user logs in I add the unique user id to the $_SESSIONS["Id"].
In addition, when the user logs out, the session is destroyed.
However, I find it unclear on how this can help me implement an authentication method without having to log in the user again and again.
So, after logging in and the app needs other information from the database, should I pass the unique userId to the PHP script to check if it's the same as the $_SESSION["Id"]?
I'm sorry, but I don't understand what you are asking.
If you set $_SESSION["Id"] on login and destroy it on logout, then that should be sufficient.
The first line of your db script should just read
if (isset($_SESSION["Id"]) {
// do stuff knowing the user is authenticated
}
I’m using Symfony2.1, a very simple login form based on documentation (http://symfony.com/doc/current/book/security.html#using-a-traditional-login-form) and a custom authentication success handler.
Anonymous user can do some action which are stored in database with the user's session ID. Now the user is logging into the system and I want to update saved actions with user's ID so that logged user can continue its work . Unfortunately in success handler I have already an updated session ID and I don’t know which records in action's table belongs to user (since they are stored with old session ID that I can’t access to [or can I?]).
What is the best practice to handle this kind of situations. Should actions be saved in database with token stored in cookie instead of session id or is there a build in mechanism and I’m trying reinvent the wheel or maybe I’m asking wrong question and therefore I can’t find answer.
The default mechanism of generating a new session id on an access level change is best practise. You could write your own authentication that does something with the new and old session ID. But unless you really know what you are doing security and authentication code is best left alone.
Best method would be as you suggest to save a token in the database and in a cookie and track your users with that. Don't forget to clean up the used tokens in the database and cookies if you no longer need them.
I am using PHP and Codeigniter to do this. Currently I am just saving a cookie to the user with their username and a $logged_in variable set to true. Then when they try to access a page, I check for the status of their $logged_in, and if they are, they're free to access.
It occurs to me that this may not be the safest way to go about this. Is there a better tactic I should be using?
It's not safe at all. Cookie is considered user input and it can't be trusted in any case.
Use sessions instead.
Also you could use some sort of custom login encrypted code (I'd personally suggest SHA1) that is matched against the login code in the database and is refreshed every, let's say, 5 minutes.
CodeIgniter offers a nice solution to this problem - You can use Database Sessions.
With Database Sessions, all the data you put in a session is stored within your SQL database. The user gets a cookie with a unique session ID that changes on a regular basis. The session ID along with IP and User Agent is used to match up the user with their session data, thus making it impossible for users to tamper with their own session data, and very hard for them to hijack someone else's session.
You can read more about CodeIgniter Database Sessions in the CodeIgniter User Guide.
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.
Using codeigniter to develop my latest project. With that said, what's the "best" way to deal with login sessions? Right now, I check the username/password against the DB. if it's a match, I set various session variables, one of them being the username. Throughout my site, I check to see if the user is logged in. I also read various blogs where people actually check the session against the php session ID of some sort.
So I guess my question is, what are some ways of making the site secure? Obviously I wouldn't keep anything in a cookie, the session would be kept in a DB table of some sort.
You are definitely on the right track there.
Authenticate credentials against the database
Store authentication state in the session data
Check if user is authenticated on each access to a page that requires authentication
To make your login process secure:
Don't store passwords in the db in plaintext, store their hashes (sha1() with a salt works well)
Sanitize any and all input that comes from the user (this includes login form data)
Don't store any data you don't want tampered with in cookies
I haven't personally used CodeIgniter, but I'm pretty sure a mature framework like that would have classes that deal with the problem built in by default.
Here is a quick tutorial for authentication in CI link
CodeIgniter do not use native PHP sessions. It generates its own session data. You need to load the library 'session ' by calling $this->load->library('session');.
What I do is to encrypt the password when the user is registering by using the Encryption class. This is done by calling $this->load->library('encrypt'); and then $this->encrypt->encode("user_password").You need to specify an encryption key by writing this in your config.php file: $config['encryption_key'] = "YOUR KEY";.
Then, to verify credentials, I get the encrypted password from the DB and call $this->encrypt->decode("user_password") and check if it matches with the password that the user wrote.
After verifying credentials, I save the info I want to store from the user in CodeIgniter's session. This is done by setting an array with the parameters desired and then calling $this->session->set_userdata($newdata);.
Example (copied from http://codeigniter.com/user_guide/libraries/sessions.html):
$newdata = array(
'username' => 'johndoe',
'email' => 'johndoe#some-site.com',
'logged_in' => TRUE
);
$this->session->set_userdata($newdata);
Then, to check if the user is logged in, you just have to test in every method if the user is logged in by calling something like this: $this->session->userdata('logged_in');
To log out an user, just destroy the session: $this->session->sess_destroy();.
In my experience there's a few stuff that the framework does for you:
It destroys the session after certain amount of time of inactivity.
CodeIgniter cleans the input data from forms. For example, if you try to enter "(" or "'" or any other characters that could break or create undesired SQL statements, CodeIgniter escapes them from you.
It rocks. It's very flexible and complete.
The user guide is your friend. It basically contains everything you need to know and gives you examples of how to do it.
No matter what you save to a session its pretty secure since its only saved on your (hopefully not shared-) hostserver. if you would like to use a cookie, please store only a token that links to the user data over the database. i'm also pretty sure that ci has a basic auth module, if not its not to late to switch to kohana for a good auth module and ORM goodness.