Security - is it ok to send a username and password via HTTP GET?

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.

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.

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.

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.