1

Scenario:

I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps with 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.

sindre j
  • 4,404
  • 5
  • 31
  • 32

4 Answers4

9

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.

Community
  • 1
  • 1
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
5

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.

Yaakov Ellis
  • 40,752
  • 27
  • 129
  • 174
  • 1
    The querystring part of the URL is encrypted and decrypted by the host, the only visible part of the router is the hostname – Chris S Feb 03 '11 at 10:31
  • 1
    @Yaakov Ellis there is a subtle distinction though, as the *parameters* on the URL are sent after the SSL handshake and so these **are** encrypted. See [this post](http://stackoverflow.com/questions/73536/are-rest-request-headers-encrypted-by-ssl) and [this one](http://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing) – dave.c Feb 03 '11 at 10:32
  • 2
    Fair enough - but as the second link from dave.c points out, any third-party tracker could record the entire url. Server Logs would contain the data as well. – Yaakov Ellis Feb 03 '11 at 10:36
  • 1
    @Yaakov Ellis I agree that it's a bad idea, I think he should implement the POST login and maintain the cookie. It's not that much effort really. – dave.c Feb 03 '11 at 10:47
  • 1
    SSL are "sniffer-proof". If you can sniff parameters you can also sniff post variables. Trackers are not a concern since the webserver runs software made by me. Browser history is not a concern since this will be used by a native Android app. The only valid point is servelogs. Granted it's a server under my control, I still don't like passwords in clear text anywhere so this is the reason I've chosen not to go that route, but use post variables insted. Thank you all for your input! Appreciated. – sindre j Feb 10 '11 at 11:24
3

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.

Community
  • 1
  • 1
mailinator
  • 39
  • 1
  • I don't think you read my question properly. This is never supposed to be a user created url, bur rather a url created and called by a silverlight application. – sindre j Apr 18 '11 at 10:44
1

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?

  • 1
    Well, if the site is compromised, then there's no point in hiding usernames and passords either is there ? ;) The whole point of protecting the usernames and passwords is to protect the site contents – sindre j Feb 10 '11 at 11:17