Is there a different way to do ASP.Net forms authentication that's already built and audited?

views:

271

answers:

+3 Q:

Is there a different way to do ASP.Net forms authentication that's already built and audited?

Like a lot of people I've gone with ASP.Net Forms authentication because it's already written and writing our own security code we're told is generally a bad idea.

With the current problems with ASP.Net I'm thinking it might be a good time to look at alternatives.

From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.

I don't really care about server farms though and I'd like to simply have an opaque cookie that demonstrates my lack of trust in the callers.

Is there a decent solution that's already been proven solid?

Update: to clarify my question. I'm talking about the authentication token part of the forms authentication that I'd like to replace. The back end is quite easy to replace, you can implement the interfaces to store your users and roles quite easily. You can also use existing libraries like http://www.memberprotect.net/ which has been mentioned here.

I'd like to change the front end part of the process to use a token that doesn't provide the client with any leverage. Sticking with the existing back end infrastructure would be useful but not essential.

I will simply recommend taking a look at InetSolution's MemberProtect product, it's a component designed with security in mind for the banking and financial services industries but is widely applicable to any site designed on ASP.NET or application built on top of the .NET platform. It provides support for encrypting of user information and a host of authentication methods from the simplistic to the very advanced and the various methods and functions are designed to be used as the developer sees fit, so it's not a canned solution so much as a very flexible one, this may or may not be a good thing depending on the particular situation. It's also a very solid foundation on which to build new member-based websites and applications in general.

You can find out more about it at http://www.memberprotect.net

I am the developer for MemberProtect and I work at InetSolution :)

Capital G 2010-09-20 13:00:15

That looks like some interesting back end stuff. How is it dealing with the front-end, the keeping track of the browser session that's logged in? It kind of looks like it's using the session id from the tutorial.

Colin Newell 2010-09-20 14:11:26

Hmm, aren't you a developer of MemberProtect? Shouldn't you mention that in your answer?

Colin Newell 2010-09-20 14:13:06

Well generally with ASP.NET sites unless you roll your own session id/token, you'll usually want to pass in the ASP.NET session id into the MemberProtect object, but there's nothing that says you *have* to, it just kind of makes sense with ASP.NET. So the tutorial lets ASP.NET handle that session id and passes it in for subsequent postbacks etc. (you are correct, updated the 'answer' ;)

Capital G 2010-09-20 14:15:11

To tell the truth while MemberProject looks interesting it's that session id/token bit that I'm really worried about.

Colin Newell 2010-09-20 15:42:30

With respect to MemberProtect, you could generate your own token/session identifier and then encrypt that and store it in a cookie, then decrypt it on a request and pass it into MemberProtect to re-instate the session, thus bypassing ASP.NET. You could also do all of this without using MemberProtect at all, I'm just saying, it supports it if you chose to bypass the asp.net session in leu of your own session identifier (granted you would still have to deal with the ASP.NET session identifier within the context of ASP.NET it is afterall still an ASP.NET application)

Capital G 2010-09-20 16:01:43

This isn't a value-less question, but I have to say that I think your logic is suspect. It's no bad idea to consider alternative authentication solutions, but the newly-announced ASP.NET vulnerability should not push you to abandon a current (presumably working) solution. I'm also not entirely sure what the relevance of this comment is:

From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.

What is it about the vulnerability that makes you think that ASP.NET forms auth is broken any more than another solution?

The detail of the MS advisory would seem to suggest that pretty much any other authentication system could be rendered similarly vulnerable to attack. For example, any solution that uses the web.config file to store settings would still have its settings open to the world, assuming a successful attack.

The real solution here is not to change security, but to apply the published workaround to the problem. You might switch authentication providers only to find that you are still vulnerable, and your effort has gained nothing.

Regarding tokens/sessions: you have to push something to the client for authentication to work (whether you call it a token or not), and it's not this part of the process that causes the current security issue: it's the way the server responds to certain calls that makes this secret vulnerable to attack.

Dan Puzey 2010-09-20 16:04:18

As far as I understand it the current token for Forms authentication contains the username. Assuming the encryption can be cracked and a token forged the attacker can login as whichever user they want to. Having an opaque token wouldn't allow that. ASP.Net isn't the only framework affected. I'm struggling to find credible alternatives to using the existing forms authentication though and I'm wondering what to do assuming I did want to do something different. I'm not a security professional and I doubt I can roll my own easily but I'd like to try something that works differently.

Colin Newell 2010-09-20 16:15:07

I'm not 100% certain, but I don't think the username is persisted to the client in the ticket. I'm not great at reading Reflector code, but check out FormsAuthentication.MakeTicketIntoBinaryBlob to see what you think.

Greg 2010-09-20 17:35:20

So what is FormsAuthenticationTicket.Name? (http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.name.aspx)

Colin Newell 2010-09-20 18:24:00

I don't know if it does. Intuitively you think that it would.

Greg 2010-09-20 19:24:45

scottt732 2010-09-27 00:18:52

+1 A:

If you have your keys in the web.config and the attacker gets to it, they are pretty much done.

If that's not the case (they don't get the keys from your .config), then afaik the padding oracle shouldn't allow them to sign a new auth ticket. The paper explains ability to encrypt by taking advantage of the cbc mode, ending with a tiny bit of garbage there. It should be enough to make it an invalid signature.

As for the video where they get the keys with the tool, its against a dotnetnuke install. A default dotnetnuke has those keys in the web.config.

Implement the workaround, keep your keys off your site level web.config, if you don't use webresource.axd and scriptresource.axd disable those handlers, and apply the patch as soon as ms releases it.

eglasius 2010-09-22 08:08:13

Are you saying that the attack figures out the machine key from by exploiting one of the .axd handlers to obtain the key from the web.config rather than by a crypto side channel?

Colin Newell 2010-09-22 08:28:30

Yes. They get pretty close before doing that though (using a crypto side channel in this step), as with the padding oracle they get the ability to decrypt all that's been encrypted with the machine key. They don't get the ability to accurately encrypt what they want, they do it by exploiting the CBC use in the encryption along with the padding oracle. The issue with that is that they end up with a block size of garbage in the encrypted message. I haven't checked into it, but one would expect those 2 handlers be used with signed values / I guess its not like that

eglasius 2010-09-22 08:45:39

That's pretty interesting. I hadn't realised that was part of their attack. I'm still surprised there is no alternative though. I get that a) there's a work around and b) they'll fix the current bug but I'd still like to see if there's an alternative that has nothing to forge.

Colin Newell 2010-09-22 09:24:24

Couldn't resist and opened the handler classes in reflector, yes, only decrypt / no signing used. The handler that do serves files is ScriptResource.axd, the other one will only reach embedded resources which one might not want anyway. Also it only calls page's decrypt, so its not signing anything.

eglasius 2010-09-22 09:39:41

re alternative: an option would be to get the aspnet forms source (if not from reflector) and only modify the specific part that sets the username in the cookie. Instead use whatever special not permanent value you'll use to track that user's authentication perhaps in that particular computer as well. Note that I can't say there aren't, just that I don't know them.

eglasius 2010-09-22 09:42:57

+2 A:

Hi,

I've been working on an HttpModule that basically does what you're looking for. When a FormsAuthenticationCookie and FormsAuthenticatedTicket are generated, before the response is sent to the client (i.e., during the processing of the postback of the Login page/action), all of the details about the cookie & ticket are stored on the server. Also, the UserData from the ticket is moved to the server (if present) and replaced with a salted SHA-512 hash of the other properties in the ticket along with a GUID that serves as a key into the server-side store of the ticket.

The validation of the cookie & tickets compares everything the client provided (optionally including their IP address) with all of the properties that were known about them at the time they were issued. If anything doesn't match, they are removed from the request before the FormsAuthenticationModule even kicks in. If everything does match, the server's UserData is stuck back in the FormsAuthTicket in case you had any modules or code that depend on it. It's all transparent. Plus, it can detect suspicious and blatantly malicious requests and inserts a random delay in the processing. It also has some explicit padding oracle workarounds in there.

The demo app actually lets you create/modify your cookie & ticket values on the server, with the server encrypting your ticket for you with the machine keys. This way you can prove to yourself that you can't create a ticket/cookie that gets around the server validation unless you write the exact set of data to the server (which should be impossible under normal circumstances).

-Scott

scottt732 2010-09-26 15:32:47

ansaurus

tags:

views:

answers:

Is there a different way to do ASP.Net forms authentication that's already built and audited?

related questions