

Replacing ASP.NET Forms Authentication - friism
http://blog.appharbor.com/2012/08/03/replacing-asp-net-forms-authentication

======
px1999
The last point in the article mentions it, but if you just drop it into your
application without taking the time to set the secret key / IV, they'll both
be set to UTF-8 encodings of "deadbeefdeadbeef".

It's odd that they didn't want to use the machinekey (though maybe there's a
reason for that), or an appsetting / custom config section for the encryption
info - instead encouraging you to use the same tickets across all of your
environments.

Also odd is that when you pass a string it uses UTF8 [or really any variable
length encoding] to specify the IV and secret key (instead of taking a base64
string, which would encourage the use of actually random values).

A third oddity is that the cryptotransforms are never reused - I know that
some can't be reused (and there is a property to indicate this) but the
solution reconstructs a transform regardless of whether this is the case.

I've been bitten by the random "Invalid Forms Authentication Ticket" issue a
couple of times (random windows updates breaking stuff, w00), and while it is
tempting to implement your own auth layer (particularly if you have a number
of apps that are running on different .net versions that need to share
authentication tickets), it doesn't strike me as the best solution to the
problem - indeed, if you have a hetrogenous system (ie are using asp.net as
well as ASP MVC, or you've got some other product that is using asp.net for
you that you don't control [sharepoint, SSRS, any of the others]), now you
probably have two problems instead of one (unless of course, you go out and
rewrite all of the asp.net controls which just go ahead and use the
FormsAuthentication class).

I really like the solution given here, but it's only suitable for a subset of
applications, and I wouldn't use it without a few modifications.

~~~
troethom
It's a good point that we probably shouldn't seed the values just to avoid
someone from accidentally using "deadbeefdeadbeef" in their production
environment. I'll also investigate if we can reuse the transformation
instances (and make the change if we can).

We didn't use the machine key as we'd have to pick one of two paths: 1) Using
the [`System.Web.Security.MachineKey`]([http://msdn.microsoft.com/en-
us/library/system.web.security....](http://msdn.microsoft.com/en-
us/library/system.web.security.machinekey.aspx)) class to perform the
encryption would probably leave us with the same issue we wanted to resolve
(the class only exposes methods for encryption, not the key itself). 2)
Parsing the configuration file manually is error-prone and makes us rely on
the current format (and while it's unlikely to change given Microsoft's
dedication to backward compatibility, it's an unnecessary dependency for an
independent solution).

Our code serves as an example and while some will probably copy the code right
into their solution, I expect most people will adapt it to suit their needs*.
[Poul-Henning Kamp](<http://phk.freebsd.dk/sagas/md5crypt_eol.html>) recently
wrote "Please notice that there is _no_ advantage in everybody in the world
using the exact same algorithm, quite the contrary in fact." (relating to the
application of well-known encryption algorithms, not designing such
algorithms). We believe it's beneficial to share a solution that people can
build and improve on. If nothing else, using different solutions prevent a
single attack from affecting us all.

~~~
px1999
Thanks for the explanation! I'm usually pretty sceptical when people step
outside the stuff provided by whatever framework they're building on
(something which devs at my workplace are always a little keen to do, which
occasionally winds up in terms of things that need to be refactored/rewritten
a few months down the track in a more standard way to integrate with some
other component or whatnot) - so it's a bit of a compulsive habit to try to
pick apart why the framework wasn't suitable. For MVC auth tokens though it
seems to be a necessary thing to actually get a straightforward and neat
solution.

It is a really nice solution, and I'm glad that you guys have pointed out that
there's a problem and actually done something about it ("hey, just set the
aspnet:UseLegacyEncryption / some other undocumented appsetting" isn't a legit
solution), and further than that, opened it up (though it all seems to have
disappeared now).

We wound up just more tightly controlling updates (and were fortunate to be in
a position that this was a solution/the problem wasn't that major), but the
backup was to serve auth cookies unencrypted and add/remove the encryption via
a httpmodule - after all, it isn't forms authentication that was really
'broken' IMO, it was that Microsoft kept changing the implementation of
encryption all the time. I get the impression that this could be a cleaner
solution for asp.net, but definitely isn't for MVC - the next time we have to
share auth tokens across multiple MVC apps / multiple instances that we don't
control updates on, I'll be sure to pick up your code and run with it, so
thanks.

------
atesti
Why has this been deleted?

~~~
friism
The post is back up now, there's an explanation here:
[http://localhost:13244/2012/08/13/the-asp-net-forms-
authenti...](http://localhost:13244/2012/08/13/the-asp-net-forms-
authentication-replacement-microsoft-doesn-t-want-you-to-see)

