I'm building a basic website where a logged in user makes requests to a server. What are some good practices for the server to verify that the user is who he says he is? Right now I create a session key every time the user logs in which is then stored in the DB. the session key is the hash of the users username concatenated with the current time. Every time the user makes a request he sends along the session key to be verified. Are there any security flaws with this method?
Yes, this isn't real security. It is know as Security by Obscurity.
If an attacker wants to hijack a session, all they would have to do is hash the username along with the time and set it as their cookie value. Of course this would have to correspond with a valid user session being logged on at that time, but they could easily script this.
For example, if they wanted to log on as bob#example.com the could simply generate the hash of bob#example.com:00:00:00, bob#example.com:00:00:01, bob#example.com:00:00:02, etc, etc, until they find a session value that allows them to access privileged pages.
Related
I plan not to use HTTPS for my web app. I used digest authentication as method to secure login to my system. And after user being authenticated, I simply send nonce to them periodically(1 min). When users make request, I simply check whether the nonce expires before I send them response.
I want to know whether it is necessary for me to protect users session_id in case the attackers replay the nonce or guess out the nonce generation mechanism? And if yes, how do I secure the session_id?
Take a look at Session Hijacking and Fixation
The best solutions to Session Hijacking/Fixation is:
Regenerate session identifier at key points. In your case after user login. So, after the user logins, we give him a new session identifier.
So,in case a hacker hijacked the session id, it would be useless and
would not work.
Save User Agent/IP address and compare it against
the User Agent/IP address used just before login. A hacker would not have the same User Agent/IP address as the legit user. But remember User Agent/IP address can sometimes be faked.
Last but not the least, destroy old session regularly.
Keeping these in mind, your program will be safe from Session Hijacking/Fixation.
So this sort of goes with my question: Authentication Cookie
Our current organization has a CAS SSO system. I manage multiple applications that all use their own sessions in ColdFusion. I could just use the SSO system to authenticate, but when a user logs out of one of my systems I want to make sure I log them out of ALL my systems, but I won't know which ones they are in necessarily. Trying to do this in a practical way. The good thing is all my applications are on the same sub-domain. SO...
I set three cookies at the sub-domain level with a 30 min expiration.
Cookie A: Contains the userid
Cookie B: Contains a string with the expiration date/time
Cookie C: Contains a HASH of the two with some SALT added in
My thinking is if the user tried to change the userid the HASH check would fail. If someone got on the machine and tried to change the expiration the HASH check would fail. Thus hopefully making this secure. And when someone logs out of my system I clear the cookie that's shared with all of them and if they return to any system they are forced to log in again. I verify the hash on each page load and refresh the cookie periodically to extend the expiration time.
EDIT: Additionally, if user logs into app1 and then goes to app2, I don't use the cookie to authenticate, I send them back to the SSO and only if they are still logged into the SSO do they get in. So I only use the cookie to log them out AND make sure they are still logged in.
END EDIT
Apart from the fact that the userid is "exposed" in the cookie is this secure/where could this fail or be compromised?
I don't want to store sessions or anything like that in a DB if it can be avoided.
The scenario is a web app running with no ability to store information locally, such as sessions. So in order to provide state, here's what I'm thinking. The server has a list of users and SHA256(passwords + salt). When a user logs in, I would set a name cookie with the username and a key cookie with SHA256(SHA256(password + salt) . ip).
This would allow the server to compare the credentials without knowing the plain text password, it wouldn't expose the password in the client's cookie, and would safeguard the logged in credentials against being ex-filtrated into an attacker's system since it would only work on that one IP address.
The only drawback I can see is that there would be no way to enforce expiry. So it would basically be a lifetime cookie for that user/password/IP combination, or at least until the web app erases the cookie or the user changes his password.
you must not use password anywhere in cookie even if it is encrypted.
give every user an id and on every login you must:
1. Update login Time
2. Create unique session Id
3. set cookie with unique session id
now on every request to server
1. validate session cookie
2. Check login time and current server time.
it is just basic structure..
Currently on our web-based apps we don't allow users to save their login information. The login itself is simply a secure cookie with a random hash which points to session information on the back end. There are no issues like HIPAA to be had, we just never implemented saving credentials, because it doesn't seem like a good idea to me.
What are the pros and cons from a security perspective on this? I worry about users getting saved cookies taken, though we do check session against IP address as well. I just don't want to miss anything.
Never 'save' the credentials, always generate a secure token that you will store on the client side and treat it as if it was the user's password (it kind of is, actually).
But first:
High value applications MUST NOT possess remember me functionality.
Medium value applications SHOULD NOT contain remember me functionality. If present, the user MUST opt-in to remember me. The system SHOULD strongly warn users that remember me is insecure particularly on public computers
Low value applications MAY include an opt-in remember me function. There should be a warning to the user that this option is insecure, particularly on public computers.
Always give the user an overview of active sessions once he is logged in and give him the option to terminate certain sessions.
You could use this strategy described here as best practice:
When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.
The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.
When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.
If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
If the username and series are not present, the login cookie is ignored.
I just started integration of OpenID in my website. All the examples I saw store the claimed IDs in cookies. How is it safe?
For example, myopenid.com returns a claimed ID that is {username}.myopenid.com
So if a hacker knows your claimed ID, he can easily hack your account.
Of course you encipher/md5 the ID before putting it into the cookies and using for authentication, but it's like storing a username without password!
Update
Now that I thought more about it, I realized, that you need to be logged in the OpenID provider, so even if the hacker gets the username, he still needs the provider's password to log in. Am I correct?
Update 2
No, update 1 is not correct :) My site cannot check whether the user is successfully logged in or not. All I receive is the claimed ID, and I just have to trust that the user is authenticated. That's really confusing...
Knowing the user's claimed identity isn't enough to authenticate.
Indeed, the user would have to be logged in to his provider, in order to authenticate with your website using that identity.
As for "trusting that the user is authenticated" -- no, you don't trust. As a final part of OpenID authentication you're supposed to verify that the authentication message comes from the provider. There are various security measures in place to ensure that the message is authentic, unaltered, etc.
If you do that, you're sure that your user is properly authenticated by the provider.
Now, since you don't want to do it every time your user makes a request, you store the session information in a cookie. However, you don't store only the claimed identifier (if you decide to store it at all), but a session id -- a pseudorandom number generated at the moment your user logs in. Since it's pseudorandom, no one can guess it, and therefore, knowledge of a claimed identifier itself doesn't mean anything.
If that answers your question, read about session management in your favorite language/framework, as it will tell you how to easily implement such mechanism, and how it works.
In summary: think of OpenID as a replacement for a password verification. You don't need to (and shouldn't) store logins and passwords in cookies, and you don't have to store claimed identifiers. Similarly, you don't verify that the login and password matches every time, but remember that the user is authenticated in a session.