Where is a users data stored in the account system that comes with asp.net mvc framework?

Question

On the first run of my mvc "hello world", i get a couple of buttons; home, about and log on. If I create a user account on the log on, where is the data stored? Is it secure enough to just leave it as is when the time comes to develop my application or should this be going to a database (if it isn't already)?

Thanks for your time.

Answer 1

ASP.Net MVC and WebForms share many of the same components including membership storage, authentication, authorization. These components are used on thousands of public sites around the internet.

Membership

The default ASP.Net MVC template uses the same SqlMembershipProvider as WebForms to store membership information. If you look in the web.config file you'll see the configuration section under the <membership/> element, it'll look like this;

<membership>
  <providers>
    <clear/>
    <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
         enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
         maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
         applicationName="/" />
  </providers>
</membership>

It references the connection string named ApplicationServices which you'll find defined at the top of the config file:

  <connectionStrings>
    <add name="ApplicationServices"
         connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
         providerName="System.Data.SqlClient" />
  </connectionStrings>

This mounts the aspnet.mdf file found in your application's App_Data directory using a locally installed instance of Microsoft Sql Server Express.

You can easily upsize this to full SQL Server by copying the MDB file to your SQL Server, mounting it, and updating the connection string.

Authentication

Authentication is again handled by the same FormsAuthentication class used for WebForms, it is also configured in the web config file:

<authentication mode="Forms">
  <forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>

Authorization

The default template also has configuration entries for SqlRoleProvider, and WindowsTokenRoleProvider which can be used to store and retrieve roles for your users from the database or ActiveDirectory respectively. Role managers are configured in the <roleManager/> element.

<roleManager enabled="false">
  <providers>
    <clear/>
    <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
    <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
  </providers>
</roleManager>

Roles are by default disabled, you can enable support for roles by changing the enabled attribute of the roleManager element from false to true.

Once you have roles configured, you can use ASP.Net authorization elements to control access to resources on your site. You can also use Authorize attributes on your controllers and/or actions for more finely grained access control. You don't have to use roles for authorization, usernames work just fine, but doing so will make management of authorization much easier.

Security

All of these modules are written using industry accepted security best practices. Authentication is handled by IIS, which can use Digest or Windows Integrated auth, both secure methods; because of browser support, anything you wrote yourself would be restricted to these methods as well.

The passwords are stored hashed in the database with a salt making brute-force attacks with methods such as rainbow tables much more difficult. The providers also support password complexity, and expiration out-of-the-box.

The authentication tokens are securely encrypted with a machine specific key and signed with a MAC to ensure that they haven't been tampered with, only then are they stored in a client-side cookie.

Testability

Even though the security is quite standard, one emphasis that MVC proponents encourage which these components don't make simple, is testing. This issue however can be worked around fairly simply with some strategically placed interfaces, a couple facade classes, and some dependency injection (which is supported by default in MVC3 now).

Answer 2

Yes, it's stored in a database. The database is in the App_Code folder under the name of ASPNETDB.MDF. You can configure it at your web.config file.

Is it secure? Well, IMHO, it is. But I really don't like this approach, I prefer to design my own authentication service and have full control over it. If you're going to stick with this method, you should read more about ASP.NET Membership Provider with Forms Authentication.