views:

103

answers:

4

I am developing a web service and I need to send a username and password to the service in a GET method. Is it OK to send this information in the uri as long as it's going over a secure channel like ssl? In other words, can I have a uri that looks like /users/{username}/{cleartext_password}?

Edit: Sorry, I think I was unclear. The web service is essentially just a database of usernames and hashed passwords. Imagine a desktop application that keeps usernames and passwords in a remote database. The end user types their username and password into the application and the application accesses the web service to authenticate the user.

So, the application will need to send an end user's username and plaintext password to the service. The service will take the username and password and check that the username and the hash of the password match the username and hashed password in the database. The application itself will have to authenticate before it can access the service, but I am just wondering what is the best way to send the end user's username and password to the service for authenticating the end user. I don't to use a POST method because I am simply authenticating and therefore not changing the state of the server. Sorry for the confusion.

A: 

Generally speaking this is not a good idea... This data will be present in a number of log files, consequently the data could be visible to people who should not see it. At the very least you should hash or encrypt it before sending it if you can.

Here is a related discussion for a little more detail... http://stackoverflow.com/questions/323200/is-a-https-query-string-secure

JoeGeeky
Or you could look into doing two-way SSL authentication. Users would need certificates the same way servers do, but the server can then authenticate the user safely.
mpez0
A: 

If it's going over a secure channel, there's no problem sending the username and password as cleartext. I'd just recommend against ever sending them as cleartext through an insecure channel and against sending them repeatedly for each request.

What you could do is first authenticate to the web service (send the username and password via ssl as cleartext) and get a token from the server that it will recognize. Then send that token with each subsequent request.

EAMann
Google, for example, allows you to send your username and password via SSL to retrieve an SID for their API ... then you send that SID in a cookie with each subsequent GET request. It works just fine.
EAMann
+2  A: 

Do this.

Send a "key" and a "digest".

The "key" is equivalent to a username.

The "digest" is a SHA1 (or MD5) hash of the key, the URI and a "shared secret" or password.

When the server gets this, it computes it's own version of the digest, based on key, URI being requested and the "shared secret" or password. Failure to match digests is a 401 error response.

S.Lott
That's actually a very elegant solution ...
EAMann
A: 

SSL does encrypt the URI, but definitely take a look at some alternatives.

HTTP Basic Auth is nice and simple, and well supported by browsers, webservers, etc

It also won't end up in log files to the same degree as URIs

NB: It's just some plain-text HTTP Headers, so definitiely NOT recommended for non-SSL apps.

http://en.wikipedia.org/wiki/Basic_access_authentication

amir75