A colleague and I had a heated debate yesterday whether it is safe to send login credentials via URL parameters as a means of authentication. He correctly pointed out that HTTPS encrypts all non-hostname/port characters in a URL before sending a request to the server side.
However, I still think there are edge cases here where it is possible to steal these credentials, and believe they should be sent via an HTTPS POST. Is this actually a safe means of sending login/token data?
Safely is a big word. SSH will keep other users from retrieving it, but do you really want to show someone's password on the querystring. What about the dude standing over the users shoulder? What about SQL injection? Really bad idea, at least tuck it in a form post.
The requested URL might show up in Web server logs and browser history/bookmarks which is not a good thing.
I had no idea that HTTPS encrypted the URL as well, it's good to know.
However, from a security perspective, I'd be more bothered by the fact that the credentials can be read in the URL bar. Not to mention possibly stored in the browser history.
As far as the transmission of the credentials are concerned, he is right. But there are many other things to consider, like brwser history, server logfiles, users watching the screen etc. which would be a risk in that case.
Take an extra step if you have a back-end database. Submit the username and password via a form post, have your back-end return a token (a guid will do), write the token to a database table and assign an expiration time, and then use that token in the querystring in lieu of credentials. Now your system will be very secure, and you have a unique session identifier as a plus.