Bad idea to pass username and password in the URL when using SSL?

Scenario:

I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps wit开发者_JAVA百科h data. The website uses forms authentication, and thus the webservices can also authenticate requests.

Now I would like to pull some data from this system to a Android application. I could implement code for running the forms login, and storing the authentication cookie, but it would actually be much simpler to send the username and password in the webservice url and authenticate each call. I don't really see a big problem with this as the communication is SSL encrypted, but I'm open to be conviced otherwise ;)

What do you think ? Bad idea / not so bad idea ?

Conclusion:

After reviewing the answers the only really valid argument against name / pass in the url request string is that it's stored in the server log files. Granted it's my server and if that server is hacked the the data it stores will also be hacked, but I still don't like passwords showing up in logs. (Thats why they are stored salted and encrypted)

Solution:

I will post the username and passord with the request. Minimal extra work, and more secure.

See Are querystring parameters secure in HTTPS (HTTP + SSL)?

Everything will be encrypted, but the URLs, along with the query string (and thus the passwords) will show up in the server log files.

Bad Idea: The contents of your post are encrypted and though the URL parameters may be encrypted as well, they could still be visible to third-party trackers, server logs or some other monitoring software that can directly sniff your traffic. It is just not a good idea to open up a potential security hole in this way.

Users do tend to copy-and-paste URLs straight from their address bar into emails, blogs, etc., and save them in bookmarks, and so on.

And things like plugins, or even other software that reads, for example, window properties (alternate shells, theme managers, accessibility software) could end up with the info. And they might, for example, crash and automatically send crashdumps back to their developers.

And worms far less sophisticated than keloggers - like things that take screendumps - can get passwords this way. Sometimes even security software, for example if deployed in a corporate network.

And if the user has a local proxy, then they might be communicating in plaintext with the proxy which in turn is talking in SSL (not the way it's supposed to be done, but it happens).

And for these and more reasons, URLs with usernames and passwords, that used to be standard - such as ftp URLs with the username and password in the authority segment - are now typically forbidden by browsers.

https://www.rfc-editor.org/rfc/rfc3986#section-7.5

So, an emphatic NO, DO NOT DO THIS.

It is always good programing practice to not provide delicate info like username and password in the URL. No matter how good a site is it can be compromised. So why provide with more info?