We have ASP.NET ( Silverlight) LOB Web application which was developed using .Net 4. Now we have to get rid of the current authentication mechanism and implement new one. I think we have two options here:
1> Forms Authentication using Membership provider ( This is available in .Net 4)
2> ASP.NET Identity ( This is not available in .Net 4. So we have to update the target framework to 4.5 or latter)
I have gone through the article here that describes the difference between these two and based on my understanding the 2 major differences are:
1> You can configured identity framework to use social credentials.
2> Identity framework code can be unit tested.
We have LOB application. So likelihood of allowing users to use their social credential to login into our application is very very less. So i am looking for suggestion whether it is really worthwhile to spend time and implement identity framework for authentication. (Note that for identity framework I will have to convert target framework of all projects to 4.5). The only advantage I see here is unit testing.
Updating to later framework is not a problem. Going back the way usually causes problem, but you won't have to do any code changes if you go from 4 to 4.5. Or rather 4.5.1 which is latest in 4.5.x.
If architecture advantage is not an advantage to you, then security must be. Identity uses PBKDF2 with HMAC-SHA256 password hashing. This is not available in MembershipProvider which comes with SHA1 as default hashing which is not considered secure at all in 2016
Otherwise I enjoy working with Identity framework - it is a lot easier to do things with rather than monstrous MembershipProvider. Some things took me few hours to implement in Identity that took weeks with MembershiProvider. So speed of development is another consideration.
Also MembershipProvider is not getting any new versions, why do you want to use old framework when a new shiny supported framework is available?
Related
I believe that .NET Identity 3 cannot run on an existing (v4.5) ASP.NET solution, but requires .NET Core. I cannot update to .NET Core. Is there a workaround for this? If not then how are people supposed to migrate from ASP.NET Membership to ASP.Net Identity?
First of all, I need to note that ASP.NET Core (which works with Identity 3) does not require .NET Core. It can be used either over .NET Core or .NET Framework 4.6.1 (or higher).
I guess you use the default approach in both cases (Membership and Identity) when all information about users, roles, passwords, etc, is stored in some database.
So, the best way to migrate from Membership to Identity is the following:
create a new ASP.NET Core project using the default template and with "Authentication" turned on
then write a small console program which will move all user-related information from your old membership tables to the new ones (created automatically by ASP.NET Identity)
then move all other your controllers and views one by one.
The only problem here - is that Identity will not recognize the passwords' hashes created with Membership. To resolve it you will need to define your own implementation of IPasswordHasher interface and register it in DI container as it's described in this article.
I am writing a new web site and am looking at Asp.Net Identity 2.0. Out of the box, it uses Entity Framework for all of its data access. For the rest of the site, we were creating middleware web services for data access. Our original plan for security sake was that the web servers would talk to middleware and middleware would talk to the database via Entity Framework. We had planned on blocking via firewall database access from the web server.
I see that I can create a custom provider for Identity 2.0 and it in turn could use middleware for it's data access.
Here are my questions:
Is it more secure to not allow the web servers to have direct database access?
If it is more secure, why would Microsoft not build it that way out of the box
If you were starting from scratch like we are, would you recommend using entity framework or writing a custom provider that goes through our middleware layer?
Thanks.
1.) It can be secure. I don't see it as a security issue but coupling issue. What if you want to upgrade or change from Entity Framework in the future? What if you want to change from Identity 2.0? What if you want to upgrade one but you can't because the other doesn't support it yet.
2.) Microsoft wanted to promote it products first and foremost. For simplicity sake if your ok with Entity Framework and Identity 2.0 and don't mind how coupled they are it could be perfectly fine solution.
3.) How much time/effort can you afford to spend on the custom provider? It might not be worth the effort to create your own provider.
Asp.NET Identity out-of-the-box is actually Asp.Net Identity on Entity Framework. It generates a database, connection string, the model files, the controllers and a context class for you, which you can redirect to your own database for it to generate the Identity tables within. Everything is very secure, and they've taken care of a lot of the authentication/password hashing for you. I wouldn't say it is worth it to create your own provider, but you can also create your own provider within Identity if you want. Identity 2.0 is great. Very easy to add custom table properties, etc.
I have an application running ASP.NET on 3.0 framework that uses form authentication. I am now building and MVC 4 application that also uses forms authentication and I would like to share authentication between the two apps. I have both config files matching for the auth tag and exact machine key tags. I think my problem is that the ASP.NET application uses the old ASP membership provider which has the user passwords in MD5 format, and the MVC application is using simple membership, password format SHA1.
Is there a way to share user authentication between the two apps even with different credentials(password formats)?
For the main app that authenticates in the forms tag I have this
<credentials passwordFormat="MD5"/>
I am not really sure if this is my issue or what's going on.
Well figured out my answer. All I had to do was add in the tag was the attribute compatibilityMode="Framework20SP2".
This was due to the fact my ASP.NET app was running on the older framework and my new MVC app was on framework 4.0
Your options are pretty much:
Write your own ASP.Net 2.0 MembershipProvider to use the PBKDF2 algorithm to store passwords (Resetting everyone's passwords will be required).
You don't get to override SimpleMembershipProviders storage of passwords (that I know of) so you'll have to writing your own ExtendedMembershipProvider to duplicate the ASP.Net 2.0 security mechanisms in the default MembershipProvider.
As a side note, MD5 is (in my opinion) a terrible algorithm to store passwords. At this point from what I've read bcrypt or PBKDF2 is recommended by most security experts.
If you're interested on the changes Microsoft made to increase security in .Net releases the article Stronger Password Hashing in .NET with Microsoft’s Universal Providers is a good read.
I heard that the hashing algorithm for asp.net membership is sha-1, but I've seen in most articles that it is no longer safe, also I would like to know if most professional developers are using asp.net membership or do they come up with their own solution/ implementation with regards to login, authentication, authorization of their system/projects.
Does asp.net membership really provide a secure and robust solution for login, authentication, authorization of web applications? :)
The reason why I'm asking is I would like to know if developers are really using it in their projects.
Sir/Ma'am, Your answers would be of great help.
If I am writing internal applications with a modest number of users then I usually rely on asp.net memberhsip. Its familiar, I know how to get it up and running quickly. Other developers also know it reasonably well so it doesn't need explaining. Its also usually desirable for the organisation to be in control of user accounts.
On the other hand, if you were creating a public site and needed to authenticate users before making contributions (eg. stack overflow), you might want to think about implementing OpenId so users don't have to create a new account with your domain. They could use Google/Facebook/Twitter instead. There are libraries to get you started.
The default hash algorithm changed in .NET 4.0 to SHA256. So you are pretty safe if you are using .NET 4.0.
You could also specify the hash algorithm in your web.config:
<system.web>
<machineKey validation="SHA256" />
<membership defaultProvider="myMembership" hashAlgorithmType="SHA256">
...
</system.web>
Actually that's was a breaking change in .NET 4.0. So if you had an existing application in .NET 3.5 and upgraded to .NET 4.0 passwords that were hashed with SHA1 might no longer be used in .NET 4.0 unless you change the algorithm type back to SHA1.
Not really. ASP.NET membership provider is a design failure.
It forces you to use predefined domain model entities instead of
using your own.
Not interchangeable with ease (Use different providers per company or different forms of authentication)
The predefined MembershipProvider abstraction is a failed class design.(out param ? - yes, please test it)
Go implement your own provider.
For passwords choose your hash algorithm (sha1, sha512...).
After finishing the implementation use FormsAuthentication class to integrate it with your provider.
I'm currently working on an application that will likely be deployed amongst various organizations within my current workplace. I need to develop a testable and properly designed authentication framework so that for each implementation folks can choose to use either Windows Authentication, Forms Authentication, a home-grown Single-SignOn system OR OpenID.
So given ASP.NET MVC (and in particular I'm using the S#arp Architecture framework) how should I go about doing this?
Ideally it would be nice if folks can simply make changes to the web.config file in each case.
Thanks
ASP .NET MVC supports ASP .NET membership provider, making it easier for you to handle Windows/Forms Authentication without any hassle. As long as you specify the required information on the web.config. The default site comes with an example.
For other options of implementation, Kigg has an OpenID implementation which also includes the unit testing code.
I guess that after learning how those work you'll find a way to include your "home-grown Single-SignOn" authentication framework :P
Update:
In order to use the membership provider using your own users table, you must implement a custom provider. The configuration through the web.config will be available anyways, but you'll need to create a class which implements the MembershipProvider abstract class.
Here's a link to a video and some source code explaining how to achieve this.