views:

468

answers:

6

I've been programming for a long time now, but I'm not the world's most experienced.Net developer. I recently picked up a project that is using Forms authentication for their website. I first looked at forms authentication in .Net 1.1 and at that time it had some limitations that made me decide not to use it as my primary form of authentication.

This project requires that users have roles (which I understand forms authentication supports) and group memberships. For example "User A" is an "Admin" for "Company A". Does forms authentication now support this sort of user structure?

I've also read that forms authentication sends passwords back as plain text. This client does not use SSL. Is this true?

The current code base uses forms authentication, but does not support groups (it does support roles). So, I need to either modify the forms authentication to support the required groups or rip out the forms authentication and use the Authentication framework I normally use. If forms authentication does support groups and is secure enough, then I should stick with that. If forms authentication has security issues or does not support groups then I need to remove that form of authentication.

I've searched the internet for a pros-and-cons sort of article, but no luck. What do you guys think?

+1  A: 

Forms authentication doesn't sends passwords back as plain text. As long as you make sure the login/pwd is protected when receiving it (i.e. using https ... ssl) there is no security risk in there.

If you really need to do authorization that way, you can rely on forms authentication for ... authentication, and do authorization with your own mechanism.

eglasius
As I mentioned, the are not using HTTPS/SSL, so that was my concern; however, I suppose it gets sent to the server as plan text regardless.I was kind of thinking I could use the forms authentication and then do my own authorization based on the ID supplied by the authentication.
mlindegarde
You can do your own authorization, but the easiest (not the only) way, would gets you the username instead of the ID - HttpContext.Current.User.Identity.Name (after being logged in).
eglasius
+1  A: 

Forms Auth is an excellent choice for what you're after. It does support roles but it does not support groups. However, it does have built in support for active directory integration, which you can use to aleviate the group issue, if necessary. Personally, I would stick with what you have and learn more about it. If you want to use Forms mode of Forms Auth rather than AD auth mode, I would consider building on group support using the existing forms auth database.

I highly recommend viewing these videos from Microsoft about forms authentication. You'll find that it's pretty straight forward to use. Granted, it's not something you can throw together as it is a fairly robust and flexible framework. You'll want to read up on it and view these videos. However, when you become familiar with it, you'll find that it's secure, supported and very well accepted by the development community.

Yikes, I just reviewed your question again and you said they don't use SSL. How secure does this site need to be? To me, that would be my first order of business is to move to SSL!

asp316
It's important to note that this is an Internet (not intrAnet) application. Can you still use Active Directory when users register for the website via the internet? I'm no Windows security expert, but I thought that Active Directory was for an intranet only.
mlindegarde
Yes, you can use an external facing AD forest and authenticate to it.
asp316
A: 

the db doesnt store the plain password text it uses md5 or some other means of hashing... i know that they are matching 2 hashed strings against each other to auth wheter they convert the string client side or server side im not sure..its probably browser... if you are thinking about using ssl i dont think you should be using ASP.net forms auth... its time for you to do your own forms based auth and dive in to some ad mining....

Sevki
+1  A: 

Forms Authentication will not support groups natively. What we do is use it to "authenticate" a user (prove who they are) and then we use our own data stores to "authorize" a user (describe what they can do).

GWLlosa
+5  A: 

To satisfy you requirements you will use Forms Authentication with Membership. If your application is using SQL Server database you can use SQLMembershipProvider as the membership provider to achieve this.

Examining ASP.NET 2.0's Membership, Roles, and Profile can be a good start reference.

About your concern about sending passwords as a plain text when the connection is not secured.

Actually the passwords that are sent are usually hashed (algorithm will depend on the Membership Provider chosen) and that is as there are eventually stored. Of course if the connection is not secured that hashed password can be retrieved and used to hack the application but at least you eliminate the possibility that the plain user password is stolen and used e.g. to access another service (as you know many people use the same password across multiple services). So to be secure you really need to use https here.

As a note of warning, I am far from being an expert in that field, but quite recently I was faced with a similar problem that you are describing so I though that you may find some of this useful.

kristof
To clear it a bit: passwords are sent hashed to the Db. Passwords aren't sent to the browser, just received when submitting the login form (where https is needed). Role provider doesn't handle his role/company req, nor the base RoleProvider (although you can get clever on it Admin-CompanyA :)).
eglasius
Thanks for the link, very informative. I would do a "Vote Up", but I don't have a high enough reputation to do that yet.
mlindegarde
@Freddy - thanks for the pointers - I should learn not to answer questions on Friday afternoon - especially if it is Friday the 13th ;). I will edit my answer when I find some free time
kristof
A: 

Thanks for all of the input. Although I think I'll continue to use my own authentication library in other projects, I think that the best thing to do for this client is to stick with the forms authentication they already have partially in place.

Although I develop with Visual Studio and the .Net platform, I don't always like to do things the "Microsoft" way. I find that many times the "Microsoft" way introduces a lot of overhead that can be avoided if you know what you're doing.

Thanks again for the input.

mlindegarde
Well, luckily nobody forces you to use something here.
Lex Li