Hi I am going to do a web service. Now our customers are going to be able to call the method from their interface. I been thinking what I should do for authentication, I been reading and can not really decide. I want to pass username and password to the method.
Do you got any advice?
Common authentication schemes are well-defined and, while not perfect, are known entities. The worst thing you can do is "roll your own" in security.
I assume by your comment "pass username and password to the method", you mean you would like to have access to the credentials used to access your web service. This is fine, but don't pass credentials as parameters to your method.
Based on your description, basic authentication over SSL should provide you sufficient protection for your application. This would work in a non-trusted environment (i.e. across unknown networks) and should be easy enough to implement on the client-side.
Related
I'm really just looking to see how much folly is in the below suggestion from a security perspective.
I have two websites. One is an administration portal and the other is a members portal.
Within the administration portal administrators can retrieve a listing of members and I need to offer the ability for administrators to login to the member portal without having to enter the members login credentials.
Both are separate websites within IIS and for this discussion lets say they are on different servers.
Both websites access the same SQL Server database.
I was thinking that I could on the administrator clicking a "Login as Member" link create a random code string and save this to the database along with the member number.
I could then pass the code and member number to the member portal as query string parameters.
The member portal then read in these values and checks them in the database to verify that the code string exists and if so that it matches the member number also being passed. I could then login the member and set a flag in the database to set the code as being used and therefore invalid for future requests.
I'm thinking to bypass this a hacker would need to successfully guess the random code and pass that to the page alongside the corresponding member number for that code and for that combination to be marked as unused in the database.
This would seem to be unlikely given that only seconds will pass between the code being generated and the code being used.
If necessary I could always check the IP address of the request as users of the administration portal all share the same fixed IP address.
So do you think the above would stand up to scrutiny on a security review or will I need to go down the SSO route?
Your approach is very sound. I can confirm because I have implemented just such a solution for just such a reason. We analyzed the options and exposure. And after implementation, our application passed a PCI Complaince Audit.
Reasons:
SSL is Esential! protects against sniffers. Essential. Without Encryption, sniffers could detect your GUID and may have a window to use it)
As Tony pointed out, the GUID is effectively unguessable.
Guid Tokens expiring should expire within 24 hours.
Suggestions:
Checking against IP is good. But don't be fooled into a feeling of security from it. Anyone can fake IP's in headers. To be Secure against XSS and CSRF by using AntiForgery tokens.
The AntiForgery token is a cookie that populates your HTTPHeaders with __RequestVerificationToken which is almost as hard to guess as your GUID.
Consider using an established Authentication framework like .NET Identity 2 and multitenancy.
An established framework takes the burden of encrypting your passwords. MS Frameworks like Simple Membership and Identity integrate into modern ASP.NET frameworks and give you very strong base of functionality to lean on.
If you're using an old framework like classic ASP or .NET 2.0, the classic Membership Provider is more appropriate.
If you are creating new MVC 5 applications utilizing Entity Framework, I strongly suggest using Identity 2.1.
Consider Mult-Tenancy. While there is nothing wrong with your solution, if Admins and users shared Membership Provider, your solution would be cleaner. An admin could log into the main site and "get" the token from the DB. Then no exposure.
Assuming the use of HTTPS and adequate physical and IT security processes and procedures in place for the administrators, this method should be adequate. It is more secure than most financial website password resets, which typically only require a compromised email account and some personal information to reset the password. If you check the IP address range of the originating client request as well, a hacker would have had to already have access to your systems or network. Also, if you make the code a GUID, it would be (pragmatically speaking) impossible for someone to guess.
You could add a layer of checking for hack attempts by storing a record in the database each time this event occurs (or at least each it fails due to a bad key), and each time it occurs run a check to see if it is happening too often (like 100 times in the past hour, or something--the right number depends on how often you expect it to happen). If it's happening too often, then have it send an alert to IT personnel and revert so that the user has to enter their credentials manually.
Disclaimer: I am not a security expert by any means, so I'll gladly defer to anyone claiming such status. I'm weighing in here due to a lack of answers.
I want to create a authorization mechanism for an application based on WebAPI and AngularJs.
I've seen some articles, which use BasicHttpAuthentication, but i really don't like the whole idea of sending username, and password on every request. The more it doesn't fit for me is because i want to use OpenId authentication, where you don't have username/password pair.
I'm thinking about a solution, but I don't really know how to implement it. The concept is that user is authenticated as in an usual Web application - posts a form with user / password or selects an OpenId provider. If the user is authenticated succesfully, it is placed in a static object, which stores the User object for a certain ammount of time. Next a usertoken is generated and passed to the Client Application. The client passes the token on each request to the server, if the user exists in the above mentioned static object with the appropriate authentication token it is authorized to get the data.
Firstly - Do you think this is a good approach to the problem?
Secondly - How should I pass the authentication token, WITHOUT using cookies? I guess it should sit in the request headers, like in BasicHttpAuthentication but, I really dont' know how to handle it.
BasicHttpAuthentication
I'm with you on feeling dirty about caching the username and password on the client and forever transferring it with every request. Another aspect of Basic authentication that might work against you is the lack of sign-off. Other than changing the password, you can't "invalidate" a basic authentication session. Tokens on the other hand, will typically offer an expiration date, and if you want server-side invalidation you can check the issue date and say "any tokens older than issue date xyz are invalid".
Server State
You mention "If the user is authenticated successfully, it is placed in a static object". But this is independent of the token? This sounds like you're wanting to implement server state management of authentication sessions, but this isn't strictly necessary. The token itself should be sufficient for user authentication, managing server state is another potential obstacle. Server state can become difficult to manage when you factor app-pool recycles or web-farm environments (what if you want two services to share the same authentication token, but not require communication with a central "authentication server" for storing the state / session?)
Passing Authentication Token
Headers is definitely a good place for it. Really, where else is there? Cookies, Headers, Message. Other than a browser client, cookies don't make a lot of sense, and including it in the message can muddy your message formatting a bit, so headers is the only remaining option that makes much sense in my view.
Client Implementation
You've not specified, but I suspect you're interested in calling the service from .NET? In which case System.Net.Http.HttpClient could be your friend. In particular, the DefaultRequestHeaders collection. You can use this to add a custom header to store your authentication token.
Server Implementation
When researching ASP.NET authentication recently, I learned a lot about customisation by examining the Mixed Authentication Disposition ASP.NET Module (MADAM). I wasn't interested in using MADAM as-is, but learning about it from that article and examining the source code gave me a lot of ideas of how I could insert my own authentication module into the web stack.
For a few reasons, the bunch I'm working for don't want to use certificates and don't like the idea of a service that can be accessed by anybody with a valid logon.
My question is how can I authenticate an application as being an official application suited for use with these wfc services without using certificates?
They are trying to avoid a situation where inquisitive customers are clever enough to retrieve the service calls and have enough infrastructure to build their own clients to use them.
I think this is hardly achievable. If you expose service you are just saying "Hey, here is some functionality you can use if you have valid credentials". Identification of calling application is just another data send in a message. So if you have clever customer who has valid credentials and valid IP (if you use some filter) he can just send the same identification from his own application. If you create some clever algorithm for creating random valid application ID you would still ship that algorithm with your client application so you would need obfuscation to secure its code from reverse engineering.
We used a magic number scheme in one job where we paired a generated magic number with a range of IPs. However we also used username passwords just one idea.
Here's the flow I'm looking for for authentication:
Attempt to pull in the user's name from windows authentication
If that failed (user is external to network), use BASIC authentication to get the username/password.
Check the username/password against the SQL database. If windows, password isn't required, if BASIC authentication and password is incorrect, prompt again
Create the Identity object with the user name, and populate the user's roles via another SQL database call
This would need to be used for multiple applications.
What would be the best method of implementing this? Creating a HTTPModule? If so, what do I need to keep in mind (security, virtual directory setup, etc)
This type of authentication is called Mixed Mode authentication (some google searches on this will get you alot of hits). We have a flavor of this running on a site I work on, however there are some quirks to our setup that have to do with odd business requirements.
Here is an article that might get you going on the subject:
http://www.15seconds.com/Issue/050203.htm
It is a big topic to give a huge detailed explanation of how you could set it up in one post.
Good luck!
We are looking to secure a bunch of ASP.Net 2.0 .asmx web services. The which will host the web services is already forms authenticated.
Is it possible to secure the web services using forms authentication?
What are the pros and cons and other possible ways to achieve this. We certainly don't want to pass a username/pwd or token in each web method call.
The thing with form authentication is that its designed for people, where as a web service is designed to be consumed by a client application. While it is possible to do the authentication like this, it's the wrong way of thinking.
The level of security needed obviously depends upon the sensitivity of data that you're working with, but I'm going to assume its at least somewhat sensitive (but less than bank transactions). You could perhaps use SSL and passing a username and password as jle suggested, while I was typing this, or you could require an api key much like flickr does.
Another more secure option is to only pass the username and password once (and with the security of ssl) and have that give out a token that is valid for a period of time. This has the benefit of protecting the password information, and avoiding the constant overhead of ssl.
As mentioned though, it highly depends on HOW sensitive the information is that you're trying to secure.
WSE is obsolete. Do not use it unless you have no choice at all.
Almost all the functions of WSE are implemented better by WCF. The remaining capabilities, those not implemented by WCF, are obsolete themselves (DIME, for instance).
It is possible, but you will need to redirect users to a login page. Another option for passing username/pw is to use the web service over ssl. If you encrypt the connection, basic authentication can be used no problem.
You should be able to use WSE to secure your service using forms authentication - though personally I've never had to do it.
Here are some resources using WSE:
http://aleemkhan.wordpress.com/2007/09/18/using-wse-30-for-web-service-authentication/
http://msdn.microsoft.com/en-us/library/aa480575.aspx
To not use WSE you'd need to implement something like this as some of the other presponders have alluded to, though I'm not sure how reliable it would be:
http://www.dotnetbips.com/articles/dbd724e9-78f0-4a05-adfb-190d151103b2.aspx