Username/Password - Is It Still Secure?

An Anonymous Coward has this privacy issue for your consideration: "I need help. My employer, a large health care organization, is developing an application to allow patients to communicate with doctors electronically using Secure HTTP. My problem is that my employer thinks that username/password is enough security for patient authentication to the system. I disagree and think two-factor authentication is necessary, but my coworkers think I am just paranoid. Online banks are using username/password for clients to access their accounts. I think they're nuts. I also think that medical information needs to be protected even more than financial information. However, I'm a security professional and well aware of the issues." Do you think that security in the digital realm has become much more complex than the traditional password scheme can handle? (More below)

The AC continues: "They have designed the system with some important safeguards. One logs in to the system through HTTPS and sends the doctor a message. The message is stored on the system, and an email is sent to the doctor notifying her that a message awaits. The doctor logs in to the system through HTTPS and replies. An email is sent to the patient notifying them a reply is waiting. The patient logs back in the system to read the reply. This system prevents private patient data from exposure in inherently insecure email.

Two factor authentication would probably delay the project a couple of years.

Obviously these online banks are getting customers. Maybe I'm just overreacting. So do Slashdotters want to have private conversations between themselves and their doctors protected by just a username and a password?"

Just as an aside, when I bank digitally, I'm forced to use https, a user name, a password and a code-phrase. Would such a system like this accord more security than just the username and password alone?

Comments

Single factor auth is not enough

[esme]

I'm the sysadmin for the PCASSO Project, which also handles medical information over the web. Our system is different: we do lab results, operative notes, demographics, and an audit trail. The next step in our development would be to implement messaging and/or multimedia.

If you take a look at our website and our publications, I think you will agree that the security strategy that the development team implemented is quite rigorous. We do three-factor auth (user/password, digital cert, challenge-response), and use non-anonymous SSL, so that both the server and the client have to be authenticated by digital cert. We also use Java for the client, instead of just a web browser, so we can protect the client enviroment a little more against trojan horses and to make the digital certs easier.

I can understand why you wouldn't want to do certs. They're difficult, require that you use something other than plain web pages, and require a time-delay to mail or pick up in person. But a simple challenge-response system shouldn't be that hard to implement.

The other main thing you should think about, and that PCASSO spent a lot of effort on, is the server security. We used a B2-rated OS (Trusted DG/UX) and implemented MAC labels in the database and OS. This is harder than using a standard OS and not labeling (the former sysadmin and I have an article in the October issue of SysAdmin magazine about some of the things we dealt with), but is far more secure.

--
-Esme

Secure authentication

[evilpenguin]

You have a multi-part authentication (sort-of). There is a key exchange involved in the https. I've worked on a similar system (for a medical insurance company).

Here's my take. Username/Password is okay, so long as password strength is sufficient. I made a modified version of crack to hammer passwords on our system and I cracked about 40% in less than a week on a 200MHz Pentium. Of course, I was hammering the passwords locally.

If you:

1) Require 128-bit SSL
2) Test password strength
3) Install active attack detects
4) Enforce password change policy

I think you are probably fine. Sure, they can be broken or compromised. The most likely compromise is inappropriate password sharing at the client. You can't prevent that whatever scheme you implement except through user education (perhaps the most important and most often neglected area of security).

While multi-part authentication tokens (a la SecureID) are pretty danged strong, I don't think they are necessary here.

By active attack detect, I mean you should have daemons (or whatever) that look for someone hammering on passwords from the outside. You can do this by simple counting and account disabling, but if you do that, be sure to disable not only in the case of successive password fails, but also limit the number of password fails you allow per unit time, even with success in between.

Why? Because an attack might well assume that you limit successive failed passwords, so they might wait for a known success before they fail again.

Consider also using network origin. Keep a list of addresses from which connects may be attempted by that user. Treat any attempt to come in from elsewhere to be a password fialure (make it work alike so an attacker can't tell you do this!).

If you limit a user to three successive failures and no more than 10 failures a month, and you force a password change every month, no one should be able to crack a password where they only get 10 guesses.

These are ways you can make a password scheme secure.

BTW, I never persuaded my client to mandate 128-bit SSL, but consider the EFF's cracker machine. It can break shorter SSL in days. That means password recovery.

I guess I can distill this advice:

How would an attacker be able to break passwords? Deny them those abilities.

If you have prevented coming around your authentication mechanism to attack your password repository directly, then the steps outlined above should make your passwords plenty secure.

Suggestions

[jd]

Ok, this one's an easy one. :) Honest!

Username/password is -NOT- - repeat - NOT secure. People choose trivial passwords FAR too often, and have a habit of writing them down. This makes them easy to obtain.

(Look out in the car park, some day, and note down everything about each car. It's make and brand, any sports gear inside, the licence plate and it's owner's name. Then, write down everything about each owner that you can find out - their husband/wife/gf/so's name, their pet(s)' name(s), their children(s) name(s), hobbies, favourite music, etc. Chances are, you now have a list of every password that person will ever likely use, unless they're security-concious.)

How to make this system secure:

There are a variety of QUICK, EASY methods of making this system much more secure than it is, without adding significant delay to the release date.

1. Client-side certificates. If the client's browser authenticates itself, then you can at least be sure it's the right computer, not an ouside cracker. This involves nothing more than rolling an X.509 certificate, using the software you already have. A few minutes work with a shell script should give you enough.
2. IPSec. Yes, I know I mention this a lot, but it deserves it. This will authenticate the machine that the person is connecting from. You don't need to generate anything for this, just install the driver on the user's machine (or get them to) and you're set. This does the same for you as the certificates, but is slightly easier to set up (for you).
3. This depends on how your system is implemented. If you make use of Java, then simply record stats of keypresses per second, average number of corrections, etc. Feed this back to the server, and if the values move outside a preset range from the person's average, lock the user out.

Medical Health Issues

[Evil Greeb]

Ross Anderson's homepage has a whole host of articles pertaining to medical issues.