If client use cookie auto login for 30 days.hacker could login and change user information when get the client cookies. How to prevent this?
sorry for my bad english!
tks in advance!
You should make sure cookies are only ever transmitted over an SSL connection. This is pretty much the only way to prevent cookie hijacking.
Other ways to help prevent (but none will work 100% effectively) is to make sure you use unique identifiers in your cookie that expire. IE, after every login, change their user ID which is stored into their cookie. This means if someone hijacks a cookie, or hijacks old cookies there is a good chance they should have expired.
by not storing any login information on the client pc. At least not automatically. If the user does so, it is up to her. But you should not encourage her to do such unsafe things.
Go here and start reading: The Definitive Guide To Website Authentication
Related
Suppose a cookie say FB's authentication cookie is encrypted and sent to me. If i use tools like wireshark, Firesheep then I can sniff that encrypted cookie. I open a new browser and inject this encrypted cookie(using greasemonkey and some scripts) and eventually it's going to work. Whats the purpose of encryption here ?
Because the point is even after encrypting I am going to send the encrypted cookie each time I click something on facebook after logging in and the sniffing tools can get that. Pls explain ????
most websites use cookie to identify user login, and yes, the cookie is visible to you. but every time you login in the website, the website would send a new encrypted cookie to you, your old/previous cookie would not be working. And cookie has a date to expire, the encryption on the cookie is to stop user calculating the cookie for login next time. If the user could have the formula for generating the cookie string, there would be no security for the website. cheers!
By the way, you should understand this for doing good things, don't do bad things, keep our Internet safe and tidy! thanks!
I've tried searching and found questions that were close to this, but I could not find one answer that actually details this exact issue.
What (if anything) prevents a user from sniffing a network, getting all the asp.net forms authentication cookies a site is sending to me (or sniff the cookies I'm sendint to the server), setting those cookies in their own browser and viewing the site as the authenticated user?
Inherently, I don't think there's any native mechanism to prevent the scenario you describe. I think that's one reason MS recommends that Forms Authentication cookies have a very limited lifespan (set a short Expiration time), and be communicated across SSL.
SSL is the only thing that can prevent it.
Reading this question,
Different users get the same cookie - value in .ASPXANONYMOUS
and search for a solution, I start thinking, if it is possible for some one to really steal the cookie with some way, and then place it on his browser and login lets say as administrator.
Do you know how form authentication can ensure that even if the cookie is stolen, the hacker does not get to use it in an actual login?
Is there any other alternative automatic defense mechanism?
Is it possible to steal a cookie and
authenticate as an administrator?
Yes it is possible, if the Forms Auth cookie is not encrypted, someone could hack their cookie to give them elevated privileges or if SSL is not require, copy someone another person's cookie. However, there are steps you can take to mitigate these risks:
On the system.web/authentication/forms element:
requireSSL=true. This requires that the cookie only be transmitted over SSL
slidingExpiration=false. When true, an expired ticket can be reactivated.
cookieless=false. Do not use cookieless sessions in an environment where are you trying to enforce security.
enableCrossAppRedirects=false. When false, processing of cookies across apps is not allowed.
protection=all. Encrypts and hashes the Forms Auth cookie using the machine key specified in the machine.config or web.config. This feature would stop someone from hacking their own cookie as this setting tells the system to generate a signature of the cookie and on each authentication request, compare the signature with the passed cookie.
If you so wanted, you could add a small bit of protection by putting some sort of authentication information in Session such as a hash of the user's username (Never the username in plain text nor their password). This would require the attacker to steal both the Session cookie and the Forms Auth cookie.
The scenario where a cookie can be stolen happens in a public wireless environment. While you or I would never operate in such a setup, it may be impossible to prevent your customers from doing so.
If the attacker knows what secure site you're connected to, the idea is that your browser can be tricked into posting to a non-secure version of the same url. At that point your cookie is compromised.
That's why in addition to httpOnlyCookies you'll want to specify requireSSL="true"
<httpCookies httpOnlyCookies="true" requireSSL="true" />
I disagree with The Rook's comment, in that I find it unfair;
#Aristos i updated my answer. But to be honest, if your using a Microsoft development platform your application will be inherently insecure. – The Rook 22 mins ago
Security doesn't happen by accident and it doesn't happen "right out of the box", at least not in my experience. Nothing is secure until it's designed to be so, regardless of the platform or the tools.
There are many ways that a session id can be leaked to an attacker. XSS is the most commonly used attack to hijack a Session ID and you should test for XSS vulnerabilities in your application. . A common method of improving the strength of a session is to check the IP address. When the user logs in, record the ip address. Check the IP address for every request, if the IP changes then its probably a hijacked session. This secuirty measure could prevent legitimate requests, but that is very unlikely.
Do not check the X-Forwarded-For or User-Agent, its trivial for an attacker to modify these values.
I also recommend enabling httpOnlyCookies in your web.config file:
<httpCookies httpOnlyCookies="true"/>
This makes it more difficult for an attacker to hijack a session with javascript, but its still possible.
I don't know the specifics of the cookie in question but it's generally bad practice to store both the username and password in a user cookie. You generally want to only store the username in the cookie along with other non sensitive information. That way the user is prompted to provide their password only when logging in.
I am working on this, and I am coming up with an idea, that I am not sure if it is 100% safe, but is an idea.
My idea is that every user must pass from the login page.
If some one stole the cookie, is not pass the login page, but is go direct inside to the rest pages. He can not pass the login page, because did not know the really password, so if he pass he fail anyway.
So I place an extra session value, that the user have been pass with success the login page.
Now inside every critical page, I check that extra session value and if found it null, I login off and ask again for the password.
Now I do not know, maybe all that done all ready by microsoft, need to check it more.
To check this idea I use this function that direct make a user logged in.
FormsAuthentication.SetAuthCookie("UserName", false);
My second security that I have all ready fix and use, is that I check for different ips and or different cookie from the same logged in user. I have made many think on that, many checks (if is behind proxy, if is from different countries, what is look for, how many times I have see him, etc...) but this is the general idea.
This video show exactly what I try to prevent. By using the trick I have describe here, you can not just set the login cookie only.
Just sharing my ideas...
We use FormAuthentication to manage logins and I have a case where a customer complains where he can login from one computer but to from another.
I can see in my logs that his authentican is successfull but he gets bumped back to the login page. I can reproduce the symptons by disabling cookies so I asked the customer to test if cookies are enabled on http://www.tempesttech.com/cookies/cookietest1.asp, but this came out positive.
What have I missed? Is there any antivirus/security software that can mess up (ASP.NET) cookies?
The user is using IE7 and claims to have F-secure installed.
First ask from your customer to try to login using some other browser like google chrome.
If with other browser works, then ask from your customer to clear the cookies on his browser, if he can clear only your page cookies, then you must be check if you using too much cookies, or too big ones, and create a diferent shecma.
You maybe have set to store/cache the roles on cookie - this make cookie too big ones, and big cookies create problems.
I want to create a website that the login system shouldn't be handled by cookies, but on (a) table(s) in the local (on the server) SQL DB.
Is there a way to do it?
Even no partial way?
What and where should I save instead of the cookie???
ASP.NET uses Session cookies by default to track user requests. If you use Cookieless sessions, you will find the Session ID being appended in all requests from the browser. In many scenarios, this could also be unacceptable.
Even if you decide to hit the database and check for a "LoggedIn" flag upon each request, you still need some way to identify the incoming request as belonging to a particular user. This could be in the form of encrypted values in hidden fields, depending on your security scenario. That said, it's not a much better method than the use of cookies, because any data that comes from the client has the potential to have been tampered with.
Personally, I think Cookies are great to track user requests as long as you encrypt them properly.
You still need some way of telling the users apart. If you don't use cookies, then you will have to transfer that information in url or allow only one user from a single ip address (this is really stupid) ... or something else. Cookies are not that bad :-).
Cookieless ASP.NET
If you need help actually implementing the login system you'll need to include more details about your specific problem.
You can store your usernames and so in a database, but you will still need a way to recognize the user as he/she navigates from page to page. That is the cookies role in this, to persist this login token...
It is possible to implement some other ways of handling this token. One can use the URL or somme hidden fields (as ASP.NET's ViewState) to store this token.
So, yes; it can be done. But it takes some work, since you can't use what ASP.NET already provides you. (ASP.NET has builtin-features to handle this token as a cookie, and also store the credentials in the database.)
Use the SqlMembershipProvider.