Can a username and password be sent safely over HTTPS via URL parameters?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

The requested URL might show up in Web server logs and browser history/bookmarks which is not a good thing.

Answer 5

There is also another solution which I am trying. You can use PHP handlers for session, to store session data directly to your database as a string easily with its handlers. You will need a session table in your DB with a expiry time. Once you send over HTTPS login data, if it is correct, you could store it in $_SESSION variable, and if you did well the interface, it will go to your DB. Since this is not exposed outside of PHP, you will have a robust login system, and in client cookies there is ONLY stored session ID rather than tokens, account or other sensitive data.

Reference: http://es.php.net/manual/en/function.session-set-save-handler.php

Answer 6

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.