Take the 2-minute tour ×

We are an organisation who have purchased a system which is used by doctors to view test results of patients (quite sensitive information). Being a programmer, I have poked and prodded with the system and found that it submits the username and password via a HTTP GET request. On the domain it is run on, all computers are set to bypass the proxy, so the URL with the request won't be saved in some proxy log somewhere. But I would argue this is an unsafe way of handling username and passwords anyway.

The vendor will argue that since we never asked for it, it will be an 'enhancement' which will require additional $$$. (We never wrote the specifications for the system in the first place).

What kind of case could I make to management to make them feel this isn't to standard and that probably the only way this system would be secure is through HTTPS?

EDIT: Thanks for all your responses! I have raised the issue with the project leader, her response was along the lines of "what's HTTP?". So I plan to explain it all to her in better detail, investigate the legal implications and try to raise the issue with the programmers directly asking why they went that path. I will also try and explain the situation to other colleagues who don't have any direct involvement but may be able to have some influence on the matter.

share|improve this question
Is there any reason for not using POST? –  different Oct 26 '08 at 22:40
POST wouldn't be any more secure than get –  Blair Conrad Oct 26 '08 at 23:06
It at least stops casual inspection of the password in history or on the screen. –  RodeoClown Oct 27 '08 at 2:47
Should be POSTed over SSL. If the original specification mandates any kind of security, then you ought to be able to get the vendor to fix it, provided you can convince the right people that it's a problem. –  Rob Oct 27 '08 at 3:18
add comment

9 Answers

up vote 16 down vote accepted

If it's medical data and you live in the United States, there is an excellent chance that access to it is subject to HIPAA regulations, including security requirements. You should review http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806.pdf. If you don't live in the United States, I would suggest that you could still point to HIPAA as relevant to the domain.



share|improve this answer
... assuming you're in the US, of course. But other countries may have similar requirements. –  TimB Oct 26 '08 at 23:17
According to MrGreen's profile, he's in Brisbane Australia... –  Kevin Haines Oct 26 '08 at 23:37
add comment

A good way to make your case is to grab a relatively technical (or bright) manager who'll understand if you show them a live ethereal trace of a login (look! here's the password for user: MrGreen. What, don't believe me? Here try it yourself!).

Only do this without asking first if you trust and know the manager, else just talk to him about this and if he doesn't believe you, ask for permission to show. If he doesn't grant it, you could point to this question or other online resource. But if they don't care, you're out of luck, I'd say.

Do the live trace, explain simply what you did (anybody on our network can do this, it's just as easy as installing this program). Afterwards explain that it's almost free to get encryption going on the system which would prevent that and that the application barely has to be modified in the least. And that it would have the benefit of transmitting everything encrypted so the records would be a lot safer as well.

Then leave that manager to take care of the appropriate permissions/budget approval/whatever.

And the only sane way to fix it overall is indeed using POST (to fix the password being sent in the URLs) and HTTPS.

What worries me the most is that people who send plaintext passwords over the network will probably have many other security flaws.

share|improve this answer
Careful, you could get in trouble for "hacking" unless you have permission from higher-ups. –  wnoise Oct 26 '08 at 22:59
True... Maybe is to tell them without doing it first, and if they don't believe you ask them for permission to show them. Of course all this is best avoided if there's a trusted, reasonable manager (which you can't count on, I know) –  Vinko Vrsalovic Oct 26 '08 at 23:04
add comment

You have two issues here, one technical, one contractual (and hence legal). I would not be asking for legal advice on Stack Overflow.

The technical answer is obvious - these guys that did your system are clowns, since they left a gaping security hole in it.

Legally, it's going to depend on which country you're in (I notice you're from Brisbane so hello from the other side of the country). Many will have medical and/or privacy legislation which may have been violated so that's one thing to check for. The HIPAA laws that others have suggested looking into are US only; we may have an equivalent in Australia but I'm pretty certain privacy laws here in Oz could be bought into play.

Similarly, you need to look over the contract (whether you drafted it or not, I'm assuming you (or your predecessor) signed it otherwise there's no obligation on your part to pay them at all) to see if privacy was a requirement. Even if not, a competent lawyer could argue that it was an implicit requirement.

You may well have to suck it up and pay the extra money - I've worked for some big companies and they tend to lay off all responsibility for anything not listed in the deliverables to the client (this is usually written into the contract). If your vendor is a competent one (in terms of business rather than client satisfaction of course), they will have done exactly this.

But first, contact a lawyer for advice. They're scum-sucking bottom feeders :-), but they are the people who will know what to do and they are best able to examine the contracts and advise you of the best options open to you. I used one about 10 years ago to get out of a car contract that I could no longer afford and, even though it cost several thousand dollars, that was much better than the alternative.

Unless they're frequenting SO, the advice you're going to get here is either skewed to the technical side (best case) or downright dangerous in a legal sense (especially since it'll be mostly based on US law). Not wishing to advertise for lawyer types, I do know you can find one here.

Best of luck.

share|improve this answer
Take a look at privacy.gov.au and privacy.gov.au/health/index.html for Federal Australian laws regarding privacy. –  Kevin Haines Oct 26 '08 at 23:56
add comment

Even when using SSL, please remember that when usernames and passwords are sent using GET, they are included as part of the URL.

This will mean that any server logs will contain the usernames and passwords as part of the logging process. Therefore you will need to secure these logs, or at least prevent the logging of the query string.

share|improve this answer
add comment

I think for your case you should insist on https - even if it is over a "secure" network.

This is similar to http basic (basic allows it in the header - which is preferable, but you can also put it in the URL in a certain format, see rfc2617 for more details).

with SSL/https, the host name will be in the clear (obviously as it has to find the server) but the other parts of the URL should be safely encrypted.

share|improve this answer
No, the host name is not in the clear, except in the DNS request. Only the IP address is needed to find the server (though the host name is in the encrypted request). –  ysth Oct 27 '08 at 2:48
add comment

This is no less secure than built in basic http authentication.

This is true, except for one subtle point, that the username & password, depending on how the system is designed, may appear in the browser window's address bar.

At the very least, I think they should POST that information to the server.

share|improve this answer
Agree, if it appears in the browser URL bar, then it's being cached on all client machines. –  Brian R. Bondy Oct 26 '08 at 22:49
If you'll do anything, do it right, POST will still send the password in the clear –  Vinko Vrsalovic Oct 26 '08 at 22:51
Or http header at least, for a get. –  Michael Neale Oct 26 '08 at 22:51
I'm not disagreeing with you guys. However, it seems like the vendor is pretty much refusing to make this right, and it sounds like the requirements are unclear. Switching from GET to POST is pretty much trivial, and with SSL, is adequate security, I figured that's the path of least resistance. –  Jack Leow Oct 27 '08 at 0:32
GET data will also usually appear in the server's access log. –  ysth Oct 27 '08 at 2:46
add comment

This is no less secure than built in basic http authentication. Just make sure that the username/password is not being cached by the client web browsers (Is it in your browser history?)

I think the easiest and cheapest way would be to require HTTPS to secure your web application. If the user goes to a URL that is HTTP you can simply redirect them to the HTTPS equivalent URL.

If you must allow HTTP access though (and I'm not sure why that would be the case), then it is absolutely not secure. You should instead implement something like HTTP digest access authentication.

I don't think that enhancing the security is something that you should get for free though from the person doing the coding. That is unless the u/p appears in the browser history.

Since you're dealing with doctor and patient information, it also sounds to me like the content itself should be encrypted, and not just the authentication. So you really should be using HTTPS anyway.

share|improve this answer
I would argue that this is less secure than HTTP basic auth, as most web servers will log URLs accessed by default, including parameters to GET requests. I am not aware of any which default to logging HTTP auth credentials. –  Dave Sherohman Oct 27 '08 at 3:41
I agree, it is actually less secure, given all of the places the GET request is recorded. –  erickson Dec 5 '08 at 1:00
"This is no less secure than built in basic http authentication." Actually, this is even less secure than unrestricted access, as it is about the same actual level of security, while providing a false sense of security. –  Piskvor Oct 27 '09 at 14:47
add comment

Usernames and passwords should never be sent unencrypted across the network, so insist on HTTPS for at least authentication. My preference would be that the username/password only be accepted via POST (so that it doesn't appear in the URL at all), but you could conceivably encrypt and encode the password so that it could be put in a GET request. I can't envision any reason why I would do this instead of a POST.

[EDIT] As others have indicated, if you have patient-related data, you may need to encrypt all communications with the server. If you are in the US, I would urge you to look into the HIPAA regulations to see what if any apply here with regard to securing the data, especially subsection 164.306 of the Privacy Rule (PDF).

share|improve this answer
Jonathan, thanks for the typo catches. –  tvanfosson Oct 27 '08 at 0:19
add comment

Was this custom software or something used by others? If the latter, consider joining or starting a user group representing all those who use the software.

share|improve this answer
add comment

Your Answer


