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.
Related
I'm working on a legacy application using ASP.NET Web Forms, and I need to implement the "Remember Me" functionality when the user logs in (as in, does not require the user to log in unless their username/password has changed). What is the best approach to doing this? I've found posts like this one or this one but these are incredibly old and was wondering if there is an updated practice to doing this. TIA!
I believe the standard generally speaking is to create some kind of unique/random token and store it in the customer's cookies. On the back end, you save that token associated to the username, so when the customer is browsing you can check the token in their cookies and compare it to what you have on file in the database. I'm sure there are a variety of opinions on how exactly to implement all that, as you can see in that first link you mentioned, but using some kind of token in a cookie is what I've seen in many places.
we are going to build a asp.net web based application but are stuck at point where we are unable to decide what authuntication method should we used? (Active Directory Authentication or Forms Authentication Provider)
80% of the application is going to be used inside the company(all the users are part of active directory) and rest 20 is going to be used from outside. This application is going to have intense permission based on user(probably control level. i.e. a grid might have differet column for user A than user B on same page)
I am just wondering what is the best way to go?
There is no reason why you can't use LDAP with Forms Authentication. I do it all of the time. Basically, I use the LDAP to authenticate the user and grab any groups that they are in which are relevant to my application. I use forms to manage the cookies and application specific permission. You can provide an alternate form of authentication as you so desire, you just need to provide a way for your application to know when to use the LDAP or the alternate method.
Many companies maintain very tight control over who can manage their LDAP permissions (and rightly so). Depending on how often you need to add/remove/change permissions for users, and how much red tape and pain you need to go through to make those changes in the LDAP system, that may represent a significant drawback to that approach.
Obviously, that shouldn't be your one and only decision point - but it's probably worth including in your pros/cons list.
I wouldn't use LDAP for authentication. It's easy to implement, but logging is less reliable because the user cannot simply log off the application, which means that if someone else comes on and starts making changes, those changes will be tracked to the user who was logged into the computer. Users should be able to click a "Sign out" button somewhere on the page and be done with it.
You can use the Windows identity with FormsAuth, which seems to strike a comfortable medium between the two approaches. The good thing about windows authentication is that it forces consistency with usernames between the application and the domain, but there are circumstances where that's not a good thing either.
when to use
windows authentication, form authentication, passport authentication, none?
I don't find on internet any relevant matter on it, although all say how to use these authentication.
But no one says which one is superior and when to use one.
Please elaborate a little on it.
Also i want to know benefit of one over another, and what is that authentication i did by now by creating table with user id and password and match the user id and password with the data table. If that can be done easily what is the need of these authentication.
It depends on the project and what you want to achieve. If you were developing an Intranet for a company obviously only to be accessed from internal computers then windows authentication would be the choice.
If you want people to register and wish to access as much information as possible then use forms authentication to get the data you require and store it alongside membership.
If you want people to come and go from your site with ease with as little steps as possible for registration, then use Passport.
Hope this helps :)
Windows authentication is generally for companies where people do something locally and server checks if the computer that is trying to do something is valid.Example: Company that accepts some requests and people working there do something with them.
Forms authentication is for whole web where you want people to access the content regardless from PC/other device? they are using.Example: Website like this.
Windows Authentication is generally used for Active Directory-enabled networks, such as Intranet sites etc. where the user's Windows credentials double as a login to the web app.
Forms Authentication allows you to use the .NET Membership/Role/Login features and control a more in-depth user database.
I've never come across a good reason to use Passport Authentication, but it's a proprietry MS single-signon style authentication method.
We are creating three different websites using asp.net but for the user part we want to implement an approach so that each user only need to create an account in any of these three sites but use the same account in other websites too.
here is what I've suggested :
create a
useracount.website.com server
then put the sql server there and implement core user account library there such as (creating/editing/etc...)
whenever a visitor needs to have an account or needs to login into out sites then we will redirect him to the useracount.website.com address and he/she should login from that point.
and for the maintaining the user's states I've suggested to using cookies.
and all of these scenarios should be implemented by asp.net and sql.
please let me know with best approach cause I feel mine is not that good specially the cookie part.
cheers.
Search for Single Sign-on in Web Farms
Here is an Introduction
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.