I want to learn how to use authentication in your web appliction specially using some algorithm to encode your password so that it may be verified through a DB/file.
can someone share any project link???
asp.net has a built-in membership infrastructure. It allows you to create users, roles, profiles and also save data to DB and use hashed passwords, so you don't need to handle all of that yourself.
Here is a reference to anything and everything you will ever want or need to know about asp.net membership:
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
Related
I am currently working on a project in which I am rewriting an old (late 1990s) web application in ASP.NET. Part of this application is a user authentication system, which is used to access a couple of pages on the site. The user credentials (username, password, etc.) are stored in a database table.
This is all pretty standard, but while working with this database I found, to my horror, that this data is stored in plaintext.
I am wondering what the best way would be to improve the security of this insecure system. Is there an easy method of taking the plaintext data, encrypting (or hashing) it, and reinserting it? Can I use .NET Forms Authentication to facilitate any of this, and is it a good option for user authentication in the new app?
Thanks!
If you are on a Windows network, I'd use Windows Auth, which uses Active Directory. That would allow your Systems Admin group/person to administer who has access to the application.
Forms Auth is a good idea if Windows Auth won't work for you.
If they won't give you the time to implement either of the auth frameworks, I'd definitely encrypt the passwords on the database. Write a Console app and encrypt the passwords using information found here: Encrypt and decrypt a string
Then you'd need to modify your existing app to check encrypted passwords instead of plaintext ones.
I have multiple websites and a Windows app that share the same database. Is there a way that I can manage the database username and password across all web.configs and app.configs? I'd like to be able to change the username and password, and then have all websites and apps use the new name. Is there something that I can use that will automate this? I currently store the username and password in a connection string.
You may have to write some custom code in your Windows app to support it, but ASP.NET Membership will let you share usernames and passwords among multiple apps.
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting
data) in Microsoft SQL Server, Active Directory, or an alternative
data store.
Authenticating users who visit your site. You can authenticate users
programmatically, or you can use the ASP.NET login controls to create
a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting
them . Depending on membership options you choose, the membership
system can also provide an automated password-reset system that takes
a user-supplied question and response.
Exposing a unique identification for authenticated users that you can
use in your own applications and that also integrates with the ASP.NET
personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to
substitute your own code to manage membership and maintain membership
data in a custom data store
Also, see this SO question for some additional info.
Keep the user name and password in the registry.
Build the connection string on the fly using a class
All web sites and Apps should have the same class
By the way, the registry is more secure than the web config.
I read this article here
http://www.codeproject.com/KB/web-security/RolesFormsAuthorization.aspx
What is the limitation of Membership that would require me to implement my own ?
The primary limitation is using the arbitrary database design of the Membership provider along with being relegated to the Membership API.
I have always found the membership provider API to be kludgy (at best) and the database design it requires to work out of box to be atrocious. I have never once used the builtin membership to fruition ... I think ever but absolutely not in any application I have in production.
So to sum it up, the primary reason to not use the membership provider out of box is the database design will not match your design and you will have a hell of a time trying to use your application database + membership database together or you will have a large amount of insidious data duplication of users, ASP.NET user vs application user.
Personally I've found the standard membership provider extreamly flexible. But one reason could be to allow your website to authenticate users against a legacy database containing usernames and passwords created by a different system, or to authenticate against a web service.
I've been researching this intensely for the past few days.
We're developing an ASP.Net MVC site that needs to support 100,000+ users. We'd like to keep it fast, scalable, and simple. We have our own SQL database tables for user and user_role, etc. We are not using server controls.
Given that there are no server controls, and a custom membershipProvider would need to be created, where is there any benefit left to use ASP.Net Auth/Membership?
The other alternative would seem to be to create custom code to drop a UniqueID CustomerID in a cookie and authenticate with that. Or, if we're paranoid about sniffers, we could encrypt the cookie as well.
Is there any real benefit in this scenario (MVC and customer data is in our own tables) to using the ASP.Net auth/membership framework, or is the fully custom solution a viable route?
Update: I found one person (Matt Briggs) who seems to have come to some of the same conclusions I have: This comes from this link: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1
ASP.net membership is a poorly
engineered API that is insecure out of
the box, is not well maintained, and
gives developers a false sense of
security. Authentication is a weekend
project if you aren't building a
framework, but still, most .net
developers blindly follow the official
APIs, assuming that a major
corporation like MS can put out
something decent.
One of the first rules of creating a secure authentication system is that you shouldn't try to build the framework yourself. There are many pitfalls that can be easily overlooked. So, I would say unless there is an overwhelming reason to do otherwise, you should use an existing framework like the MembershipProvider.
To list "the benefits" requires listing all security measures that were taken by the FormsAuthentication classes which is a long list. Off the top of my head, I can think a few:
Hashes of passwords
Protection against SQL injection
Protection of the cookie that stores the authentication ticket
Use of and storage of a ticket instead of say a username in the cookie.
Checking on every page to ensure the user is authenticated
Population of the IPrincipal and IIdentity for the current user
Redirection after login (granted a feature)
Handling of failed login attempts
Locking and unlocking users
ActiveDirectory integration
Ability to easily set and change password length and complexity requirements.
Salting (from Hightechrider)
....
I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.
If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.
If not, build your own, but if you do, make sure you add salt and encrypt your passwords, and do a proper encrypted cookie please.
Just to clear up a potential misconception, using the customer ID, encrypted or not is extremely vulnerable to sniffers. What you want to do instead is create a log in ticket at the time of successful authentication and store that ID in the cookie. This won't protect sniffers from stealing sessions, but at least the session (eventually) expires whereas the customer ID does not.
You can implement your own membership provider (as you mentioned) if you wish to have your own storage. One advantage is that you can administer memberships through IIS' .NET users configuration tool.
The biggest advantage is what the others stated already; why reinvent the wheel?
If you implement your own custom login UI using MVC you could reuse also when switching for a different membership provider.
You can customize to build your own provider. Behind the scenes the Membership provider uses the same FormsAuthentication implementation as you will write. Anyway, I have read that the main issues about the performance you will face will be related to the SQL SERVER stored procedures that retrieve the data. In one of the books about building a portal system by Omar Al Zabir he mentions some improvements to the stored procedure which can result in faster performance.
Other than forms authentication, what are other common forms of authentication that an application should ideally support?
Is it just active directory or is LDAP a must also?
Generally, you only need to support one kind of authentication.
With forms authentication, you have to provide a database table containing user names and passwords. And you should provide the ability for users to change their passwords, etc. This is all made easier with the Membershp provider.
If you have the option of using Active Directory or another LDAP, that removes the burden from you of establishing logins and maintaining them. If that choice is available to you, I'd recommend using it.
Likely you only want to support one form of authentication. Here are a couple other than Forms authentication that you can use.
Windows Authentication: http://msdn.microsoft.com/en-us/library/ms998358.aspx
OpenId: http://www.eggheadcafe.com/tutorials/aspnet/4b3c7c9b-fe80-4e6e-a34e-0e9efed5c575/integrate-openid-authenti.aspx