Security - is it ok to send a username and passwor

Question

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.

Answer 1

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.

If your vendor tries to push back with an additional fee, say "Are you saying that you're not compliant with the relevant governmental standards? Golly, maybe you should provide us with complete documentation on your security and privacy standards, safeguards, and procedures. Because obviously if we got hit with a fine, we'd be coming after you. " (IANAL and all that.)

From a technical level, certainly the suggestion of an ethereal trace showing how easy it is to scavenge usernames and passwords should be eye-opening to your management. Given how trivially easy it is to sniff normal network traffic and how easy it is to use SSL for transport, the idea of a vendor pushing back on that as a "security enhancement" is outrageous.

Answer 2

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.

Answer 3

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.