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.
Related
I have to maintain user log-in that is authenticated by webservice (SOAP WSDL) in PHP, it returns id_session if logging successfully, there will be function to return error if the given id_session expired.
When Logging in with the user credential, I use ajax in a specific php file to verify it, so the result will be receiving from ajax response (JS), how would I use it to maintain the session in php?
if I use cookie to maintain it only, is it enough? is there a way to store the session id encrypted securely but still can use it?
The only idea I have is storing it in cookie, & remove the cookie's value when it's expired which does not seem to be good practice.
First of all never store a plain password in a session. Also you should check the session everytime the user does something (refresh page, do a query, ...)
Also sessions aren't available in JS. You are probably thinking about cookies. And those aren't secure cause they can be tampered with if wanted to.
I have simple problem, I have js application (frontend) that uses my PHP REST api. I need to implement simple token based authentication and I'm not sure how that should work since i dont use sessions in REST. From my understaning it goes something like this:
User tries to login, if valid credentials, I generate token and return user object with token
I update user token in database
Client holds user object in cookies or local storage instead of session and with every request he passes token in header
I check if there's token in DB, if there is (I know which user is sending request)I proceed with request, otherwise I send him to login page
If token expires or user signs out, i update token field in DB with NULL or empty string (not sure if this is needed).
I just need confirmation if this is ok approach or i misunderstood something in protocol.
Thank you all in advance
Thank you
I don't think this approach is stateless. The existence of the token represents the logged in state. Which means that a part of the client state is maintained by the server. In other words the token count on the server increases by the client sessions.
each request from client to server must contain all of the information
necessary to understand the request, and cannot take advantage of any
stored context on the server. Session state is therefore kept entirely
on the client.
- Fielding - REST - stateless
I would rather do something like this:
Send the username and password at first auth and return a token with meta-data signed by the server.
Send the token by every other request, so the server will be able to verify the signature and use the meta-data, which can contain for example user id, expiration date, etc...
Update the token before it expires.
Update the private key of the signing mechanism regularly.
Cache the authentication and authorization data with an in-memory cache. I think db is too slow for that. Be aware that the whole process MUST work without cache. So if you clear the cache and send another request, and it does not work because the cache is lost, then it violates stateless constraint.
This way you will avoid storing the token (and so the client state) on the server. Not a perfect solution (e.g. the token can be used by others before it expires) but it is stateless. I am not sure whether you really need REST or token based auth. (Be aware that these applies on human to machine communication. Machine to machine communication is usually authorized differently.)
By stateless. it means that the in REST server does not store any state about the client in session or any other form.
I have personally used something like this for an app and this is the simplest form of security you can have.
When our system used to issue access token it create an expiry date/time also along with it. everytime you make a call with a specific access-token its expiry date/time updated +n hrs
I am building a website and I am using sessions to check user login. I am wondering if there is any better and safer way to check user login. Because sessions are stored in the clients computer I think they are not very safe and easy to hack. Am I correct?How do big websites like facebook and twitter check if their user is logged in or not. I am new to PHP so dont say my question is too basic.
Sessions are not stored in the client's computer. You must be confused with cookies !
Sessions are definitely the way to go here.
No matter what you use as authentication, if the client computer is compromised, the client's method of authentication can be abused. So in this regard, any other way can only be as safe as sessions are.
All big sites use sessions, usually in conjunction with cookies.
I want you to first understand that Sessions are the only way you can identify a client.
You don't store sessions on either the client or server side. (If you want a secure system.)
First you need to understand the need for sessions, only then you can know what sessions are.
The internet is a stateless network of machines, each with their own identifiers. Most of the communication that we do while sending a request to load a page or visit various links are over the HTTP (Hyper Text Transfer Protocol).
HTTP is a stateless protocol, meaning any communication over this protocol is not required by the protocol to be stored on either the server or client.
Let us understand what this would mean, with an example:
Suppose you try to login to http://example.com
You fill the form, hit the send button.
All the data in your form is then sent to the server.
The server checks if the username and password received was right. If right, it sends you the secure data.
In your next call to the web server, you expect to be logged in. BUT, due to the stateless nature of HTTP, your server does not recognize you anymore.
You can make this work by sending your username and password with every call, but that would mean having to enter it every-time for each request.
Here comes the role of cookies, you set the username cookie as Joe and password cookie as qwerty. Now everytime a request is sent the cookies are sent by the browser and you are happy.
This scenario now again has a problem that you need to make an authentication check everytime on your server thus increasing the load on it.
Enter Sessions. Sessions mean states with some context. It may be a logged in user, it may contain preferences you have set or any other similar stuff.
Here, when the user is logged in the first time, the server generates a session ID. This session ID is then stored by the server in a DB, File or it's Memory (RAM) along with any other data like username of the person who is logged in, preferences etc.
The server response then contains the session ID, which may be in the form of a cookie, HTML5 session states or sometimes even hidden fields.
Now, every call the client makes, contains the session ID. The server then checks its session store for any valid sessions with the same ID and get into context therby giving a pseudo state-like mechanism to communications taking place over HTTP.
How long your browser stores this cookie can also be determined by the server while sending the cookie.
There are advanced techniques for further security like changing the session ID each time a call is made, but lets get into that only if you want me to.
Cheers! :)
I want to learn the whole details of web application authentication. So, I decided to write a CodeIgniter authentication library from scratch. Now, I have to make design decision about how to determine whether one user is login.
Basically, after user input username & password pair. A cookie is set for this session, following navigations in the web application will not require username & password. The server side will check whether the session cookie is valid to determine whether current user is login. The question is: how to determine whether cookie is valid cookie issued from server side?
I can image the most simple way is to have the cookie value stored in session status as well. For each HTTP request, compare the value from cookie and the value from server session. (Since CodeIgniter session library store session variables in cookies, it is not applicable without some tweak.) This method requires storage in server side.
For huge web application that is deployed in multiple datacenters. It is possible that user input username & password when browsing in one datacenter, while he/she access the web application in another datacenter later. The expected behavior is that user just input username & password once. As a result, all datacenters should be able to access the session status. That is possible not applicable even the session status is stored in external storage such as database.
I tried Google. I login Google with Asian proxy which is supposed to direct me to datacenters in Asian. Then I switch to North American proxy which should direct me to datacenters in North America. It recognize my login without asking username and password again.
So, is there any way to determine whether user is login without server side session status?
No, that's impossible.
These datacenters is not isolated from each other but interconnected.
It is distributed but solid "external storage such as database"
Cross-domain authorization is another matter but easily achieved too.
What's the use anyway of such an information - just the fact the user logged in, without any user options, credentials - anything? Why without a database on the server side?
Useful resources:
session_save_handler allows you to replace PHP's file-based session handling by your own mechanisms, e.g. connecting to an external database
this SO question deals with mySQL replication.
This is only one of many issues when going multi-server with a PHP solution - I'm sure there is more to find on the topic in SO's search.
Also, consider looking on Server Fault.
Assuming that the user is authenticated just because something which looks like a session cookie exists is a very bad idea. Also your code is going to become very messy when you start trying to measure facts about the session without calling session_start() first. A better solution is to store the fact the user is authenticated (and potentially some of the authorization infromation) in the session itelf, e.g.
session_start();
if (!$_SESSION['auth_user']) {
if ($_POST['username'] && $_POST['password']
&& check_valid($_POST['username'],$_POST['password']) {
$_SESSION['auth_user']=$_POST['username'];
} else {
// user is not logged in
header('Location: /login.php');
print 'You are not logged in';
exit;
}
}
C.
So, is there any way to determine whether user is login without server side session status?
Yes, there is. The server should set a cookie with encrypted user ID (and possibly other data). If all servers share the key, then they also know how to decrypt that cookie, and thus can independently authenticate the user. If the cookie also contains unencrypted user ID, then you can use a custom one-way encryption function (aka hash with salt or MAC) to check if it's valid. If you really care about security, you can encrypt more data e.g. IP address, expiry date, etc. If you want, you can also use asymmetric encryption, with public and private keys, and/or digital signature.
So I'm trying to write a php SOAP client that requires the user to pass their login credentials for the remote SOAP server. Here is the set-up/dilemma:
User logs into local site using local credentials and goes to page with SOAP client.
User is now prompted for credentials for remote Soap server, which, by the way, are the same as the ones used to get into local site (9 times out of 10) via POST form.
Client passes credentials in the SOAP header along with the SOAP request, client outputs SOAP server response.
Script ends, user sees output data.
Now the user wants some other bit of data related to the original output. Problem is, that $_POST variable is now long gone. User must include credentials along with the next request. Repeat until user decides that it's easier to look up the data via another method and gives up on cool SOAP client.
The server hosting the Web Service can be accessed directly via a web client, and authentication is maintained via a cookie. However, when the server is queried via the WDSL, it doesn't look for any cookies or other browser-side session; it just checks that the SOAP request contains the credentials in the header.
So there are two versions of this question:
1) Is there a way for the local-session credentials to get passed to the SOAP request, thus keeping the logins down to one? (Be aware, I have no control over the authentication method even on the local side. This is handled by a home-grown Apache mod that controls authentication for any and every user throughout the system, covering dozens of departments I have no jurisdiction over. I have looked through the Global Variables and see no hint of the credentials, but I could just be daft about some basic security features of PHP/Apache).
2) Is there a safe and secure way for PHP to handle the credentials after the secondary login so that these credentials can be used for some set amount of time (say, a 30 minute session?). Keep in mind that, based on the first point, these credentials are very confidential, therefor there should be no simple way for someone to poke around and get these credentials to echo out (or get into some DB to see them, etc.)
Sorry if this sounds paranoid. I'm not used to handling security credentials beyond a simple "This is where you put in your password...Good, now that everybody knows each other for the rest of the session, I can get back to outputting useful stuff."
Even a link to any basic security features would be a helpful start.
Create your own expiration session. Create a database table which is:
CREATE TABLE session (
ID int unsigned NOT NULL PRIMARY KEY AUTO_INCREMENT,
Hash binary(16) NOT NULL,
User int unsigned NOT NULL,
Created timestamp
);
When the user authenticates the first time, create the session and return the hex form of the Hash.
Subsequent calls do not require the user name and password, just the hash. After, say, 5 minutes of inactivity, the Hash is deleted. User name and password are passed just once, the hash is used as authentication thereafter, and expires after a period of non-use.
Why don't you set a cookie yourself that has the username/password in it after the first soap request? You ask just one time then store in a cookie. You can then set a time out and query it while the user is logged in. You will probably want to delete the cookie on logout.
The cookie would contain the soap user/pass only. This way you would not have to worry about someone poking on the server and finding others credentials. This effectively does the same thing as having the user entering it every time since it is sent in clear text anyway. You could obfuscate the username and password in the cookie with a reversible hash or simple 2 way encryption.