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..
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.
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.
I'm developing a web application and I'm having difficulties in implementing a log in feature.
In my application, a user has to log in to add a new item(row to a database and corresponding user id is added to the newly created row). Also, the user can navigate to different pages in the application, which all requires the user to be logged in. So, once the log in is successful the user id can be stored in a cookie file to share it with all pages. But I realized that, an user after using his credentials to log in, can then alter the cookie file and change user id in the cookie to someone else's and then view confidential data of the another person. How to prevent this type of attack ?
PS: I'm using servlets and JSP for my app.
An approach would be to, instead of storing the user id in a cookie, store an authentication token in the session cookie; this token needs to be unique per user and very difficult to guess. For this you could hash and salt the user id to generate the authentication token.
For extra security, make sure that the token expires at the end of the session or after the user logs out.
It would also help to do this over HTTPS, so that your traffic is encrypted.
Here is a very good guide to web based authentication.
When a user logs in, I give them a cookie named auth with a value that is a GUID, which expires in 2 weeks. I save the hashed GUID in the database with a salt of their userID and then date when it expires. When a user accesses the site, I check for the cookie and log them in if it matches and hasn't expired in the database.
At some point before the 2 weeks is up I was thinking about updating the row and increasing the expire date.How often do you do this? Every page request seems too often since I will be constantly writing to the user table.
I was also considering changing the auth cookie value at this time. The downside of this is you cannot be authenticated at multiple computers / browsers.
I could accomplish this via a session cookie, so that it this rewrite only happens once per session. When a user accesses a page, I check for a session cookie named authenticated. If it's not there, I give them a new auth cookie value and authentication session cookie and bump the expiry times in the DB and auth cookie. If it is, I just validate off of the auth cookie.
It seems like StackOverflow never changes their auth cookie until you log out and log back in. This seems to make it more vulnerable to session hijacking- if you get the auth cookie, you have access to the users account until they log in again. Since their auth cookie won't expire or change the user will not be logged out by you logging in.
Do you allow a user to log in from multiple locations/browers?
If not, how often do you change their authentication tokens?
It depends on the level of security, places where I have worked it normally has to be kinda high.
No we do not allow people to log in from multiple browsers.
We make people login again after 20 minutes of inactivity. Depending on how accurate you want to be on timing the person out determines how often you want to update the token. I've been places where it the expiration time is updated everytime the user sends a post back to the system.
Hrm I found all of my answers here. Looks like I need a join table >.<.
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/