views:

143

answers:

3

Hi. I got a web service that I protect with basic authentication and use ssl. to make it easy for the clients that are gone use this web service I want to skip the 401 and send the credentials with the url (I would like so the customer can access the web service with url from their code / web app), question is this possible?

I know about headers but a lot of the clients gone use this do not got the proper developing team to do code.

thanks

+4  A: 

Well, you certainly could, but you really shouldn't. Sending information in plain text in the URL is bad, since that URL may get cached in several different places and generally unnecessarily exposes sensitive information. You could encrypt it before sending it, but that's probably more trouble than it's worth.

The accepted method for using a purely URL based authentication is a token of some sort. You'll need to go through a standard login procedure to generate the token though. Addendum: Also note that that's better than putting the plain text password in the URL, but still has it's share of problems. URLs are more widely logged, cached and bookmarked than other header information. At least you retain control of the token though and can expire it after some time, whereas a password in the URL can't simply be expired.

If you're developing an API, I think it's reasonable enough to require some authentication procedure. If your clients can't do it, offer a library or code snippets that'll help them.

deceze
Dejan.S
SSL'd Basic Auth is good, SSL'd Digest Auth would be better. Either one's good enough if the passwords are strong enough.
deceze
Dejan.S
Not sure what you're asking for, as long as the protocol is secured the backend system doesn't matter. You should be able to use this authentication method with any system.
deceze
@deceze, although I agree with you on the first part Basic + SSL being good. I didn't get the point were you said "URL based auth is a token of some sort". Are you implying to create a token and stuff the token in?? Because, no matter what kind of URL you create, anyone who sniffs on it will be able to impersonate easily! What am I missing?
Rahul Soni
Well I was into if example a php system can send header credentials requesting a web service. But I can ask php people for that, I just want to do something that clients with all kind of systems can use the web service with basic auth. Your answer has been helpful thanks m8
Dejan.S
@Rahul If anyone's sniffing the request, they could as well sniff POSTed data or cookies at the same time. In that regard, a token is not any more or less secure than sending plain text passwords. Over an SSL'd connection it wouldn't make much of a difference in this case. The difference is that a token can be expired in a timely manner on the server, so the attack window is smaller. You could also go extreme and change the token on each request, making it not reusable.
deceze
@deceze You can't sniff POSTed data over SSL, even if you use network capture tools. On the other hand URL is something that needn't be sniffed. Even IIS Logs + Proxy/Firewall logs will have it. Anyone who just "monitors" the log files can crack open the secure page!
Rahul Soni
@Rahul The URL is part of the encrypted HTTP headers, nobody should be able to *sniff* them. The URL is only visible to both end parties, namely the browser and the receiving server. A proxy would need to use certificate replacement and be trusted by the client to be able to see URLs (man in the middle). If somebody can see the URL of an SSL encrypted request, they can also see the rest of the HTTP headers. I agree that URLs are more widely logged than POST requests, but in terms of who has access to what part of the request it doesn't make any difference.
deceze
Yep, agreed! The point that I want to make is that once the request reaches IIS, it will be logged regardless of http or https. Hence the IIS log files will contain the URL and querystring in cleartext. If anyone opens the logs, he will be easily able to crack the username and passwords.
Rahul Soni
A: 

I can't agree more with @deceze. Sending password in URL is bad and completely defeats the purpose of having SSL. On the other hand, if you use BASIC + SSL, your body is encrypted. This implies that the password that you POST (using a FORM -> UserName & Password field) can't be decrypted by anyone in between due to the SSL being in operation.

I also don't completely agree that URL based auth with some token will be good, mainly because however you encrypt it (or not!), the URL is anyways going through all the hops as a query string to everyone. Hence anyone who can read the URL and impersonate.

HTH, Rahul

Rahul Soni
A: 

WARNING: As others have mentioned, this is a VERY BAD IDEA!

However, in the interest of answering your original question, assuming you are using basic authentication, you can embed the username and password in the URL like so.

http://userid:[email protected]/

This will make it much easier for your users to use the API, and for hackers to circumvent your security. You are only marginally better off than just turning off authentication altogether.

WARNING: As others have mentioned, this is a VERY BAD IDEA!

JohnFx
@JohnFx, by default this is not supported by the latest versions of IE. http://support.microsoft.com/default.aspx/kb/834489?p=1Hence, I would just re-iterate what you said... Passing the UserID/PWD in URL is a very bad idea!!!
Rahul Soni
I did not know that, but I'm glad to see they dropped it.
JohnFx