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.
Related
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?
What is the difference between Simple Membership and Membership in asp.net? Is Simple Membership introduced in mvc 4.0?
ASP.NET membership was the traditional approach for authentication, authorization from the microsoft team.But, with the release of mvc 4, they introduced new improved version with name Simple Membership.Simple membership relies on Extended Membership Provider
Behind the scenes, the SimpleMembershipProvider and the ExtendedMembershipProvider, as well as DotNetOpenAuth are all at work.
These changes was the need, because many web sites no longer want to store user credentials locally. Instead, they want to use OAuth and OpenID so someone else is responsible for keeping passwords safe, and people coming to the site have one less password to invent (or one less place to share an existing password). With these changes it is easy to authenticate a user via Facebook, Twitter, Microsoft, or Google. All you need to do is plugin the right keys.
Summary:
1)SimpleMembership has been designed as a replacement for the previous ASP.NET Role and Membership provider system.
2)SimpleMembership solves common problems developers ran into with the Membership provider system and was designed for modern user / membership / storage needs.
3)SimpleMembership integrates with the previous membership system, but you can't use a MembershipProvider with SimpleMembership.
4)The new ASP.NET MVC 4 Internet application template AccountController requires SimpleMembership and is not compatible with previous MembershipProviders.
5)You can continue to use existing ASP.NET Role and Membership providers in ASP.NET 4.5 and ASP.NET MVC 4 - just not with the ASP.NET MVC 4 AccountController.
6)The existing ASP.NET Role and Membership provider system remains supported, as it is part of the ASP.NET core.
7)ASP.NET 4.5 Web Forms does not use SimpleMembership; it implements OAuth on top of ASP.NET Membership.
Hope, you got the clear concept of your question.
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 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 am moving a legacy winform app to the web and would like some advice on forms authentication. Am I correct in assuming that forms authentication is better than rolling up my own user authentication functionality?
It would be easy enough to roll my own since the this is what the winform application did and the table structure already supports it, but forms authentication looks like it would do a much better job securing the site and the user authentication info.
I'm an old programmer, but pretty young in web dev and I have learned over the years that using MS built in tools sometimes looks better than it works...forms authentication isn't one of those cases is it?
Thanks!
I'd say that Forms Authentication is a case where you're likely to experience no "buyers remorse". You can opt in to use some pretty nice features. The model is very flexible because it allows you to implement your own Membership Providers.
Using forms authentication doesn't means you don't get to use those tables. You will do the check for username/password, and tell asp.net that the user is authenticated. Asp.net will continue from there, ensuring further requests from that user are identified and authenticated (based on an authentication ticket).
Update 1: Later on asp.net included membership providers, with some controls for it. Even then you can still implement your own membership provider, which in really simple cases you can do by implementing only 1 or 2 of the methods. If you have several features, and they don't map well with what the membership provider supports, I would stick to a custom implementation.