I'm currently setting up PHP to use LDAP authentication, but looking to use cookies so that we don't have users logging in every time...
Does anyone have any suggestions on the best way to use cookies to authenticate with LDAP continually over a set period of time? (storing the password obviously being the main concern)
Thanks
I suggest using adLDAP http://adldap.sourceforge.net/
Store in your database a token (phpsessid) when the auth is made with a timeout.
On every page create a check_session function that verify the phpsessid if it's still valid.
I implemented this last week and it works like a charm.
Hope this helps.
Related
I'm developing a login page for a very small site, and for the "remember me button",
I use the user-id which then I encrypt before placing it in the cookie, and when i want to check if he already has a cookie, i uncrypt the value and connect with the user-id given.
But I'm sure that's not secured enough and people will just have to set a cookie with a random value with encrypting and this will make the job, isn't it ?
As solution to this could be to generate a random token, put it in cookie and in database. Then, if you have the token, you can connect.
If user get stolen this token, this is not the page problem isn't it ?
But I don't know how to process differently..
Anyone has a solution ?
To simply answer the asked question: You can't.
Cookies are stored on the users computer and with enough access rights and/or knowledge the user will be able to delete or modify any cookies your website set.
Encryption is taking information and make into non-sense so no one can access the information. If you need encryption is up to you. But I think this kind of session management is implemented already in a lot of ways. One of the simpler would be some kind of "dynamic API Token"-implementation - Storing some kind of Hash-like String in the cookie and in DB. If they match -> login, if not -> logout. (Symfony example: https://symfony.com/doc/current/security/custom_authenticator.html )
Another one would be JWT (JSON Web Tokens), these are indeed encrypted because they send information back and forth.
If you want to implement something like this yourself I would suggest to look at documentation about these two to start.
I'm new to Android/Java programming and I came across an issue where I have to use PHP session to keep the user logged in (persistant login), this has a set of methods form using httpclient cookie or using SharedPreferences and it made think of this solution instead of using session,
1- Login the user with backend with HTTPs, this will happen only the first time the user login, the app I'm working on requires one time login and no logout mechanism. the user name and password will be sent by SMS after installing the app.
2- If user exist save the save the user/pass(could be token here) in SharedPreferences
3- Whenever the user needs something from the backend send the user/pass over HTTPs and the backend will reply if the user/pass(could be token here) is correct.
My question is, do you think the overhead of checking the user/pass or token with every request is a bad idea?
The reason I'm asking this is that PHP session ID use the same method by checking the file that has the session variables which looks like the same overhead caused by checking the user/pass or token against DB.
I don't think there's much diference, what I actually do is create a token which contains the user identifier encripted with a salt, that way you can just verify credentials at the login and then use that token during the session, you can then easily retrieve the user on the PHP and do whatever needs to be done. I woulnd't recommend passing the user/pass every time, more query complexity and risk of credentials steal. About the session... I've never messed with it for a REST based service called by a mobile device client just because I don't see the need, guess it depends on what does the service do.
I am working on a site that has a login API. So when people login on my site, they will automatically be logged in to other sites.
Is their way by which a session can be setup so that other websites can use it? If not, is their any other solution?
One way - you can store your session values in database, and can use in other sites. :)
Example:-
let suppose if my site is deployed on multiple servers and end user might be redirected to different servers accordingly to traffic, then it would be good to save the session values in db.
Yes. It's possible using in example Redis for the session storage. You should look for configuring php sessions to use custom storage. Here is php man for this http://php.net/session.customhandler
What you want to do is probably using a cookie that is spread over your whole domain. This cookie can then be linked to a session. I'm currently working on something like this on Symfony2.
As example:
login.mydomain.com
application.mydomain.com
etc.mydomain.com
login.* will obviously contain my login logic + forms etc. This will also contain an API which the other applications can verify the cookie to. My Application will first check if the user is logged in. If not, it will check if it has the required cookie. If it does not, it will redirect to the login.* login page.
If it does have the cookie, it will validate this in my login.* API. Expired > redirect to the login page, if not it will return the required info of that user and "login" to my application.
The only problem I have at the moment is storing the session. I use mcrypt to encrypt the contents and store it in mysql (cookie_id, cookie_contents). I have but 1 problem, it doesn't automatically purge the expired sessions, I still have to find a solution for this.
What you are basically looking for is Single Sign-On (just a guess, but I think accurate).
I need to make a script to authorize a user to browse a certain part of a site. That user has a software installed that make a url call. that's it. After that I know the user is authorized. How can I make my browser aware if the user has made or not that request? Is there a way? with cookies or http authentication?
Thank you
You know about sessions? You could e.g use a PHP Script. Writing all about sessions would be too much to explain here ... but try e.g. searching for php sessions.
You need to use sessions. Here is an example using sessions and MySQL to authenticate users: http://www.dreamincode.net/code/snippet1153.htm
PHP sestion is one of the solutions (The easy one) to authorise and identify the user.
Check this tutorial: http://www.tizag.com/phpT/phpsessions.php.
other option is HTTP authentication with PHP.
http://php.net/manual/en/features.http-auth.php
I am trying to secure my sessions. While doing some research, I reckoned that PHP's PHPSESSID+random hash based on Agent and IP is good enough to secure against hijacking. What else can you do, really.
I am using HTTPS for the login. As far as I could understand, the session data from PHP is never sent to the user, but rather stored on the server-side. The client only gets the id for the session. The session data holds the actual webapp's user session, which in turn is used to check if the login is valid. All fine and dandy.
However, there is a detail I can't find anywhere. I would like to to know if the cookie containing the PHP session id is automatically marked secure if I am using HTTPS. I did some google searches but never seemed to get the right search string because i only find ways of manually sending cookies. I would like to know because if that cookie is sent clear-text, it would compromise some of the security via man-in-the-middle.
EDIT 1
This is an addition for #ircmaxell
I tried out your method but somehow I still get the cookie when I switch from HTTPS back to HTTP. The way it should work is the following. Whenever the server is aware that a user session is available, it sets the secure flag. This means that the entire site runs on SSL as soon as you are logged in and refuses to give away/use the cookie whenever you don't use SSL. Or at least, that's the idea.
if ($SysKey['user']['session_id'] != '') {
session_set_cookie_params(60*60*24*7, '/', $SysKey['server']['site'], true, true);
}
I assume I need to regenerate the id since the Browser already had the cookie before the login but since I can only try it out in a few hours, I'll ask here before trying
NOTES TO SOLUTION
I just found out that you have to set these settings before starting the session. That was my problem. I am now using 2 different cookies. One for the regular guest that is sent via http, and a second for logged in users that is only sent via ssl.
Don't even think about rolling your own session handler!
PHP's session has been broken many times, and because of this it has been made more secure now than ever before. When a new issue is found it will be fixed quickly and for FREE.
However, you might want to add these options:
session.cookie_secure=True
session.cookie_httponly=True
session.use_cookies=True
session.use_only_cookies=True
I think the function that you're looking for is session_set_cookie_params(...). It will allow you to set the secure cookie flag to make it https only.
You can check via: session_get_cookie_params()