8

I'm working on an application which uses the Session variable to keep track of users, checking on the master page for it's existence otherwise knocking them out to login. I wanted to change this over to Form Authentication as I read it was more secure and the data is encrypted.

Can someone tell me what data is actually encrypted? I tried setting up Forms Authentication on my site, it works fine, users are being tracked properly and can't access pages without logging in. However, when I look at the Request Body, using Fiddler, I see all the forms fields and there content. Can't a hacker use that to change the data and resubmit the request, like they would with a cookie generated from a Session variable? This application is not using SSL, so I understand SSL would encrypt the body, but I thought that's what Forms Authentication would do also. Otherwise what does it encrypt, just the Session ID in the cookie?

Here is the code I was using:

    <authentication mode="Forms">
  <forms loginUrl="default.aspx" name=".ASPXFORMSAUTH_Test" defaultUrl="home.aspx" protection="All"/>
</authentication>
<authorization>
  <deny users="?"/>
</authorization>

in the login page I tried to manually create the cookie:

                    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
                    txtEmail.Text,
                    DateTime.Now,
                    DateTime.Now.AddMinutes(30),
                    false,
                    txtEmail.Text,
                    FormsAuthentication.FormsCookiePath);

                // Encrypt the ticket.
                string encTicket = FormsAuthentication.Encrypt(ticket);

                // Create the cookie.
                Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket));

                // Redirect back to original URL.
                Response.Redirect(FormsAuthentication.GetRedirectUrl(txtEmail.Text, false));

I had also tried:

FormsAuthentication.RedirectFromLoginPage(txtEmail.Text, false);

eariler, got the same results, request body in Fiddler shows all fields being submitted and their contents.

Paritosh
  • 4,243
  • 7
  • 47
  • 80
  • 1
    Not an answer to your question (I guess the cookie value contains some hash info, but not sure.). Anyway, you shouldn't set the cookie manually. You should rely on FormsAuthentication.SetAuthCookie. Some details here : http://stackoverflow.com/a/15199149/1236044 – jbl May 14 '13 at 14:50

3 Answers3

2

Switching your approach to Forms Authentication will not make it more secure. It will mean that you will be using a more standardized authentication mechanism so that it is easier to audit your software for authentication-related issues.

Also FormsAuthentication usually is able to work even when the Session expires for the user (or application pool recycles) since it stores the user data in an encrypted cookie with its own expiration policy.

Knaģis
  • 20,827
  • 7
  • 66
  • 80
2

You should not handle user credentials or other sensitive data without SSL.

Whether or not you use SSL, the data posted is always visible from the client, and can always be "faked". SSL (if used properly) can protect from "the man in the middle" listening in to the communication, but it's important to realize that it's of close to no use at all if not rigorously implemented, and therefore you should also consider using Strict Transport Security, even if it's not supported by all browsers.

The session ID is not "encrypted", but a session id (in practice) cannot be "guessed". HTTP(S) is stateless, and there is no way you can determine if a request from a certain client in itself is malicious or not. Any request will carry all the cookies from the client, encrypted or not (of course, if the data inside a cookie is encrypted it's hard to fake it's contents).

What can and should be done is to try and protect cookies from escaping their proper context, being subject to e.g. XSS and CSRF attacks. FormsAuthentication uses HTTP only for its cookies as default. To ensure all cookies on your web are HTTP only, put the following in your web.config:

<httpCookies httpOnlyCookies="true" />

To ensure all cookies are bound to a secure connection, use:

<httpCookies requireSSL="true" />

Now, the main reason you should use Forms Authentication before your own is that it's a proven solution. Broken authentication and session management is no 2 on the OWASP Top 10, simply because it's harder than you think to get it right.

Forms Authentication also adds the benefit of being very configurable, and properly encrypting the user credentials in store (if you tell it to do so). The standard implementations are by no means bullet proof in the light of modern GPU based brute force possibilities, but at least it's not done wrong.

If you want to know more about how the standard implementation goes about its business, you can use any of the freely available decompilers.

Oskar Lindberg
  • 2,255
  • 2
  • 16
  • 36
  • When you say the data posted is always visible from the client, you mean if i use or don't use SSL, fiddler running on my machine will always show me the request body unencrypted. However, if someone installed fiddler on a server, which i would hit from my browser, without SSL they would see my request body but with SSL they would see if encrypted? – Paritosh May 14 '13 at 15:52
  • That's the theory, yes. In practice a "secure" connection may still be compromised as with CRIME, BEAST or Lucky 13. SSL is not a uniform standard in the sense that compression and other modifications may applied, and in turn exploited when flaws are revealed. This is one among many interesting and fairly recent news articles on the subject: http://arstechnica.com/security/2013/03/new-attacks-on-ssl-decrypt-authentication-cookies/. As always, security is about mitigating risk, and mitigate we must - it's not likely we will see a "secure" web anytime soon, other than in a relative sense. – Oskar Lindberg May 14 '13 at 17:11
  • I see that I may have misread your comment, so just to be clear - the "theory" as I put it, is that if traffic is secured with SSL, it should not be possible to eavesdrop. On a side note, with digital signing it is possible to make sure that any data (encrypted or unencrypted) has not been altered along the way between sender and receiver. – Oskar Lindberg May 14 '13 at 17:26
1

Forms authentication uses the FormsAuthentication object to set a cookie for the user. The cookie contains the identifying information of the user. I'm not sure whether that cookie is HTTP only, as HTTP only cookies are only available on the server, not the client. These cookies are decrypted on the server, it grabs your user ID, etc.

So if it's not an HTTP only cookie, that could be a problem, with the exception of the information is encrypted, so the user would have to decrypt and know the underlying key. Session I thought only the session ID was tracked securely, not the actual info. The user's info is still stored on the server.

Lastly, the first and most important defense that people mention these days is SSL. You can get certificates for as cheap as $10 from what I found...

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
  • When I look at the cookie in Fiddler, I see it contains this: .ASPXFORMSAUTH_Test=BE08825FDBCD2B2679CDBA0095CCECXBE5117A7BC81022C5C142870B6576B943C4984F362318D5121FB28F644AE9B7EDC957F537AB83A839BA0511BB068AFFE067175A9D538F7B3C96DE8E22F0A3D8B4A6DB631298DD26607D8A72B1081979BBAB02D8CE8908C88A9CDE8EB8C26F709EAF7B376C59DBA227467C974CDDC634K6 that i'm guessing is the encrypted data, do you know what that is, it is just the SessionID? The request body I still see open in Fiddler, but that looks like it's the ViewState, guessing the only way to protect that is via SSL then. – Paritosh May 14 '13 at 15:00
  • 1
    It is the encrypted data. Note Forms authentication has nothing to do with Session ID, so SessionID does not play into it. Viewstate is also encrypted to by it's nature. Encryption is not 100% perfect, but very, very hard to break, and probably can only be broken by a small part of the population that is very skilled and willing to spend a lot of time to break it. More commonly, someone may try a brute force attack or a replay attack. – Brian Mains May 14 '13 at 16:21