I'm developing a cloud application. I'm confuse about my login system implementation, which one is best for me?
What about Asp.net Membership class?
Secondly about the Form authentication and Session Implementation
Remember this application is on cloud, so please give suggestion according to scenario.
I would suggest ASP.NET Membership Class. Its an industry standard and it eases handling of many login related features including:
User lockout after certain number of login attempts.
Security Question and answer.
Password encryption and hashing.
Session management.
Especially considering it being on the cloud, if you were supposed to lets say up the security for the site by making accounts to lock after one failed login attempt, it would be just a Web.config change.
Being a completely tested solution, ASP.NET membership provider is best approach.
Related
I am using Asp.Net/C# and Visual Studio 2008 to build an application.Right now I want to create a login page for my application , I would like to ask you guys , what would be the best approach to it.Should I go with Forms Authentication in Asp.Net or Should I try looking at Ajax Login with Asp.Net.Which would be more appropriate.If possible please let me know some of the pros and cons of the approaches.Also could anyone suggest me some links for a good starting point.
Any suggestions are most welcome.
Thanks
I think you have to go for Forms Authentication. below is advantages of it.
1) users do not have to be member of a domain-based network to have access to your application.
2) Web applications, particularly commercial sites where customers order products, want to have access to user information. Forms authentication makes these types of applications easier to create.
3) Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies.
4)Consider reducing the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain access to your application with a spoofed identity.
List the steps to use Forms authentication in a web application?
1.Set the authentication mode in Web.config to Forms.
2.Create a Web form to collect logon information.
3.Create a file or database to store user names and passwords.
4.Write code to add new users to the user file or database.
5.Write code to authenticate users against the user file or database.
Hope this info is helpful to you make decision
Use OAuth for login.
It has ASP.net binding too..
http://oauth.net/code/
I'm using VS2010,C#,SQL Server to develop my ASP.NET web app, although this is not my first ASP.NET experience, but this time my project is more attack-prone and I should consider better security polices. I have a login screen as my first page, users enter their user name and password and a page specific to them is showed, in my last project, I used query strings (a userid) along with sessions for security purposes, but this time I've used just query strings, it means that at the moment one can enter myaddress.com?userid=1 and visit a page in my site!!!
I know this is not good, but what are my approaches, of courses I'm not working with banking or financial systems but I'm going to have an standard security policy, I should use sessions? cookies? can you suggest me an easy-to-develop and meanwhile secure way of implementing protection policies? any sample code or tips?
thanks
ASP.NET actually comes with all of the facilities you need to provide a secure site out of the box so you don't have to worry about all of these things yourself.
Use the built-in ASP.NET Membership features and you'll be fine.
I have an existing production application that uses vanilla ASP.Net Membership for authentication.
However, I'd like to provide other means of authentication as well as the current ASP.net membership system, such as Facebook.
The Windows Azure Access Control Service makes this extremely easy and straight forward. Provided, that is, you're starting a new web application from scratch.
So, in this case, how do I
Integrate the Access Control Service authentication into my app without affecting the current login system and its users?
Migrate users over or Link logins? ( not sure if this is even possible)
Thanks all
Roberto
You need to create a custom identity provider based on your membership database. See this article on custom WS-Federation Identity Providers that can be integrated to access control: http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspx
Also see this article on one that was written on top of the membership database: http://blogs.msdn.com/b/vbertocci/archive/2009/04/23/enhance-your-asp-net-membership-based-website-by-adding-identity-provider-capabilities.aspx
Approach of creating an identity provider (IP) based on your ASP.NET membership database which Paul Tyng suggested is valid.
However, it means that if you just create an IP you'll allow log in to all people who are authorised with other IPs (e.g. Google or Facebook). I'm guessing it's not what you want - you'd still want people to first register (either plainly with username-password or with their external identity). If that's the case then your task is the following:
Add a data store for users' external identities which is related to your existing Users table.
Modify the ACS login handling within your application to check that the identity returned from ACS actually exists in your members database.
Perform member log in (instead of federated log in) if you found the returned identity in your db.
Add external identity tie in during the registration process so your Identities table can be actually populated.
(optional) Re-use the bulk of the #4 mechanism to provide an ability to attach external identity to existing user accounts (i.e. I already have a normal membership with you and now want to add an ability to log in with Google as well, for example).
There is no one single tutorial/walk-through to achieve this (or I have not found one) so I had to pull bits from a variety of sources to make it work. Please let me know in the comment if I understood your requirement correctly and I'll add a guide on how to set this up. Cheers!
Might be a bit late, but check out the following blog posts by fellow Windows Azure MVP - Dominik Bayer:
Mixing Forms and Token Authentication in a single ASP.NET Application
Mixing Forms and Token Authentication in a single ASP.NET Application (the Details)
Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)
Invaluable readings which will help you in any way!
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.
Question is:
LDAP authentication required
Internal users automatically authenticated, external users requires login
Where do I store complex access control rights?
In the AD/LDAP or in the Application itself (asp.membership db).
What is your experience and best practices suggestion?
Looking to build this in asp.net mvc 2 and using membership features, so best practice here i guess is that we roll our own custom provider to acomplish this...
I would have to say the best approach to this would be to adopt single sign on using membership login, but then implement your own access control for fine grained application access rights internally in your own system.