How secure is basic forms authentication in asp.ne

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 server control on login.aspx. The details are as follows:

• The site is configured to use the SqlMembershipProvider
• The site denies all anonymous users
• Cookies are disabled

The are obviously many things to consider regarding security but I am more interested in the zero code out of box experience that comes with the .net framework.

If, for the sake of this question, the only attack points are the username/password textboxes in login.aspx, can a hacker inject code that will allow them to gain access to our secret.aspx page?

How secure is the zero code out-of-box experience that Microsoft provides?

Answer 1

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.

Answer 2

If configured correctly through the membership provider, you will have a adequate level of security. Outside of that, access to that page might be accessible through cannonical attacks, but that has to do with your general security. I gave a presentation on using the Security Enterprise Application Blocks. You might want to read up on those and look into that when implementing security on your site, and just be aware of common security threats. No site will ever be 100% unhackable, given that you are on an open shared network and total security would be an unplugged server locked in a safe guarded 24/7 by the military (around DoD "A" level security, based of Orange book). But the out of the box functionality of the Membership Providers (when configured correctly) will offer a good amount of security.

Edit: Yeah, I agree with the other comment that was made, HTTPS on at least the log in screens is a given, if you want to protect the username/passwords from packet sniffers and network monitors.

Answer 3

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 4

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 5

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 6

As far as I know password will be sent as plain text (but encoded). So the most important thing to do is to use HTTPS protocol on login screens.

The other setting seems to be secure for me.