How secure is basic forms authentication in asp.net?

Question

Imagine that you have a simple site with only 2 pages: login.aspx and secret.aspx. Your site is secured using nothing but ASP.net forms authentication and an ASP.net Login serv

Answer 1

With HTTP Basic Authentication, which is what the .NET basic forms authentication is using, in order to view the secret.aspx page, the browser must send a Base64 encoded concatenation of the username and password.

Unless you utilize SSL, anyone who has access to scan the network between the server and the browser can read this information. They can decode the username and password. They can replay the username and password in the future to gain access to the secret.aspx page.

That said, unless you use SSL, someone can also scan the whole session of someone else using secret.aspx, so in effect, they would have access to the content of the page as well.

Answer 2

Well, try and look behind the scenes:

Password Protection

Applications that store user names, passwords, and other authentication information in a database should never store passwords in plaintext, lest the database be stolen or compromised. To that end, SqlMembershipProvider supports three storage formats ("encodings") for passwords and password answers. The provider's PasswordFormat property, which is initialized from the passwordFormat configuration attribute, determines which format is used:

• MembershipPasswordFormat.Clear, which stores passwords and password answers in plaintext.
• MembershipPasswordFormat.Hashed (the default), which stores salted hashes generated from passwords and password answers. The salt is a random 128-bit value generated by the .NET Framework's RNGCryptoServiceProvider class. Each password/password answer pair is salted with this unique value, and the salt is stored in the aspnet_Membership table's PasswordSalt field. The result of hashing the password and the salt is stored in the Password field. Similarly, the result of hashing the password answer and the salt is stored in the PasswordAnswer field.
• MembershipPasswordFormat.Encrypted, which stores encrypted passwords and password answers. SqlMembershipProvider encrypts passwords and password answers using the symmetric encryption/decryption key specified in the configuration section's decryptionKey attribute, and the encryption algorithm specified in the configuration section's decryption attribute. SqlMembershipProvider throws an exception if it is asked to encrypt passwords and password answers, and if decryptionKey is set to Autogenerate. This prevents a membership database containing encrypted passwords and password answers from becoming invalid if moved to another server or another application.

So the strength of your security (out of the box) will depend on which password protection format strategy you are using:

• If you use clear text, it is obviously easier to hack into your system.
• Using Encrypted on the other hand, security will depend on physical access to your machine (or at least, machine.config).
• Using Hashed passwords (the default) will guarantee security depending on: a) known reversals of the hashing strategy of RNGCryptoServiceProvider class and b) access to the database to compromise the randomly generated salt.

I do not know if it is possible to use some sort of rainbow table hack into the default Hash-base system.

For more details, check out this link: http://msdn.microsoft.com/en-us/library/aa478949.aspx

Answer 3

You still have some variables that aren't accounted for:

• Security into the data store used by your membership provider (in this case, the Sql Server database).
• security of other sites hosted in the same IIS
• general network security of the machines involved in hosting the site, or on the same network where the site is hosted
• physical security of the machines hosting the site
• Are you using appropriate measures to encrypt authentication traffic? (HTTPS/SSL)

Not all of those issues are MS specific, but they're worth mentioning because any of them could easily outweigh the issue you're asking about, if not taken care of. But, for the purpose of your question I'll assume there aren't any problems with them.

In that case, I'm pretty sure the forms authentication does what it's supposed to do. I don't think there's any currently active exploit out there.

Answer 4

Cookies over URL is not secure enough, there are so many different problems with it (especially referrer leakage if you've got any) and usage of HTTPS.

Answer 5

Here are two good articles from Microsoft on the subject:

How To: Protect Forms Authentication in ASP.NET 2.0

INFO: Help Secure Forms Authentication by Using Secure Sockets Layer (SSL)

Answer 6

Asp.Net supports cookieless sessions, as this blog post shows. Instead of a session cookie, it uses an identifier in the url to track users.

I am not sure how secure this is, but I would think it is a secure as the difficulty to brute force the identity string.

It looks like it works more or less out of the box, however when redirecting a user and wanting to maintain session state you must include the session id. The blog post shows how to do that, as well as many other articles on the web.