Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a very basic idea of how these work. I've used them many times when I needed a user management system rather then writing my own. But should I use these for a production system? Would windows user accounts actually provide more security then these accounts in the database tables, given a small user base with verification of new users before activation?

I do believe that this system of course is more secure than anything I could write, but are there any hardening measures I should be taking or a 3rd party provider that's much better?

share|improve this question

migrated from Jun 17 '11 at 21:13

This question came from our site for professional programmers interested in conceptual questions about software development.

up vote 3 down vote accepted

How secure they are is dependent entirely on what you are wanting to defend against, and what you are wanting to defend. Defending against an internal employee who wants to look at their colleague's sales records is different from an external attacker who wants to steal customer information, which is different than defending against a government who wants to steal your proprietary designs.

generally speaking, these providers are not insecure as they follow the basic recommendations like salting passwords, allowing you to change the hash algorithm, etc (including non-crypto stuff as well). However then you get into the configuration problems like making sure the connection to SQL is secure, the page you POST your credentials to is over SSL, or that the session cookies are protected via SSL, access to the database itself is secure, etc.

Comparatively, Windows Auth has similar problems, and then you get into security boundary issues, as it becomes a pain to use Windows Auth over the internet.

In theory an Active Directory store is probably going to be more secure than an average SQL Server database, but in reality if all you are using it for is user authentication on a public website, its likely VERY insecure because it probably isn't treated as nicely as the corporate AD. Then again, corporate AD probably isn't treated nicely either (in general, not necessarily in your case).

SQL databases are prone to SQL injection attacks, Active Directory stores are prone to Windows-specific attacks. SQL databases tend to lead to identity sprawl... multiple user accounts for multiple applications spread across mulitple databases. Active Directory leads centralized accounts. Either could be good or bad, it depends on what you are trying to accomplish.

Writing your own providers is usually not recommended as they haven't gone through public scrutiny, whereas the providers built into .NET have. 3rd party providers run into the same basic problem. How have they been tested?

And then this brings up a question of why are you letting the application handle authentication itself? Maybe it's better to let someone else do it via Claims Based Authentication. This pushes the risk onto another system like Google, Facebook, or Windows Live.

share|improve this answer

Since you have used the membership API many times, you know it can be configured to store credentials in plain text. Also the .NET Framework 4 web.config can be set to use DES | 3DES | AES, but these days it is better to hash the passwords more than once.

share|improve this answer
Hi Matt, welcome to Information Security! Don't forget to check the FAQ, and give a quick read at How to Answer. Btw - "the standard these days is to hash the passwords twice" is incorrect, best use is something like bcrypt, which internally uses thousands of rounds (but dont try to rehash by yourself...). – AviD Nov 8 '12 at 7:21
AviD is right, point taken about standards. Also regarding the Membership API, the usernames and passwords are easily changed by anyone with DB write access. Even if they are hashed and salted you can just overwrite them with a know hashed password with salt, then login to the account. When you are done just put back the original values. You will have an audit trail for the web login, but none for the password change. – Matt Shirilla Nov 8 '12 at 11:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.