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

Passwords -- Yes and No

[Erich]

Yes, good passwords are sufficient combined with SSL.

No, passwords are not sufficient.

The reason is that most passwords that people pick are not good passwords. Most users will select "12345" or "bird4me" instead of "7yhX%^I]w." Also, many people are not very security-aware, and so will be installing various trojans that could capture keystrokes.

My suggestion is to use a password and an iButton. Put an iButton on a serial device and have that as additional authentication. All iButtons have a unique serial number. iButtons are from Dallas Semiconductor and lots of information can be found at www.ibutton.com.

Re:User/pass

[radish]

Not true. I implemented a (prototype) secure web email system which simply locked the account for 10 minutes if you got the password wrong 3 times. You could brute force it, but it would take a real long time!

I think that username/password is perfectly secure from a _technical_ point of view - the problem is people write down/share/give away their passwords. Of course this is up to the user in question, when it's their medical data at risk they may be more careful!!

And of course the following rules should _always_ be used:

* Change passwords at regular intervals
* Proactive account lock outs
* SSL encoded password transmission
* Crypto secure passwords (e.g. non-dictionary words, punctuation, numbers etc)
* Minimum password length

As an aside...I can see why banks are targets (I work for an major bank and our dialin systems are secured with one-time key systems) but why would someone want to pretend to be me when talking to my doctor?? What would motivate the cracker in question to spend however long it takes to bruteforce/man-in-the-middle this website?

Fine, just expire the password after bad tries.

[brad.hill]

I don't see anything wrong with a username/password and HTTPS to protect my security.

However, if you're REALLY paranoid, just disable all access to the account for 24 hours if they enter a bad password 3 times in 24 hours. The time to brute force such a system quickly goes into years when that happens.

Fincancial vs. medical privacy

[Mr. Slippery]

I don't worry too much about using only an id/password combination on my bank account, since an attacker is limited in the damage they could do. Sending a check from my account takes a few days to clear, so there's a good chance I'd catch it before any damage was done - and writing a check to yourself from my account seems like a pretty good way to get caught, no? However, one could still do mischief by sending a check from my account to some third party (a contribution to the KKK, for example), and an intruder could get my credit card number from my online bank account. But the same risks apply if you got hold of my physical checkbook.

I'd be much more worried about medical records. (At least in general principal; there is, at the moment, nothing too terribly embarassing in them.)

Doesn't the HTTP 1.1 spec allow for some sort of challenge-response authentication? I think that would be significantly more secure than a simple password scheme. Mandating some sort of smartcard on the doctor's side would also be a good idea, but might be difficult to implement.

Re:Why not PGP?

[sammy baby]

A good idea, but near impossible to implement in the real world. It's not realistic to assume that all these doctors and patients will be willing to learn to use PGP. My department contains less than 20 people, and trying to get /them/ to use PGP for sensitive information was hard enough in itself. The original poster describes a "large health care organization". You're talking, at the very least, hundreds of patients who would all have to install PGP, generate keypairs, post public keys... the technical support issues would be nightmarish.

Passwords *can* be enough...

[Tet]

... but they aren't always. If someone really places such little emphasis on the privacy of their medical records that they choose a non-secure password, then they deserve everything they get. IMHO, society is trying to hard to protect the stupid from themselves. It's always going to be a losing battle, and we should just let them get on with it.

That said, there are, of course, problem with the above reasoning. First and foremost is that the general public doesn't know what is and what is not a secure password. Most people will assume that if they don't tell anyone that their password is "elephant" then it's secure. Those of us that have ever done tech support are constantly amazed by the number of people that continue to use either their username, birthday of car registration for passwords. Furthermore, password authentication has some undesirable properties. Passwords can be cracked without the user knowing it, and once public, they can never be reused.

I'd say that for your application, single password authentication is about the best you can hope for in the near term. Certainly lobby management for better alternatives, but don't hold your breath. I've been there before, and a multibillion dollar global corporation I used to work can still be brought down by any unauthenticated user that knows how. I tried to explain just how vulnerable they were, but all they were interested in was getting the product in and running. Sigh.

Re:"Good" passwords

[slim]

It's difficult to talk about this without seeming like a patronising bastard, so I'll apologise in advance.

There are a lot of stupid people out there, and once you start enforcing password quality rules, they'll get confused. Faced with something like the RedHat password quality checker, which requires a non-dictionary-word, and doesn't allow stuff like "t3th3r" or "gr0up13s" either, many people will either give up, or write the password down.

The more complex the restrictions, the harder the passwords become to remember, and the more likely they are to write them down.

One nice idea would be to make users accept some form of licence, which makes it clear that if *they* compromise their password's secrecy, you're not liable.

For more security, I guess you'd need some form of swipe-card or something (or the calculator thang described elsewhere), which would obviously up the cost of the project.
--

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.

Safe? Yes, with considerations

[Enoch Root]

As a Security Professional, I'm sure you realise it's not just in the user/password authentification that lies your security.

Yes, as long as other security concerns are accounted for, a username/password combination is more than enough, and while I think 'paranoia' should be on every security specialist's list of valuable skills, I think you're not focusing your paranoia in the right place.

The concept of username/password is that of unforgeable identity. As long as you're capable of acknowleding without the shadow of a doubt that someone on the network is who they claim to be, you got the security you want. However, in practice, it's a bit harder to implement.

You can stick with a username/password scheme, but here are the other concerns you need to keep in mind:

Password encryption: Having passwords is one thing, but you want them to be unreachable to everyone. A shadow password scheme with good encryption on the passwords is invaluable! Also make sure password information always transits securely.

Single step authentification: Seems simple enough if username and/or password are incorrect, you shouldn't tell which one is wrong.

User management: Another important fact is to make sure no one can create an identity out of the blue.

Password rules enforcement: You don't want people to set their passwords to 'Fido' or to 'Password'. Code a password enforcement scheme. If you're really paranoid, enforce min. 7 chars length, mixed case, alphanumeric chars, and make a dictionary check. Also, make sure users are forced to change their passwords each month.

User awareness: The most important, and often most neglected aspect of password management. You want your users to understand that writing down their passwords in their agenda is not a good idea. They should not spread them around or lend them to others. Informed users are the best way to keep a system secure.

So, is the username/password scheme still revelant in this day and age? Yeah. The theory behind it is sound; whether you simply give a password prompt, or use biometrics, it's the same concept applied a different way: that of 100% authentification.

I think you're wasting your energies in the wrong direction. Making your system fool-proof against intrusions, monitoring your security output, these are all safe and sound practices and the issue is not the concept of passwords itself.

"The wages of sin is death but so is the salary of virtue, and at least the evil get to go home early on Fridays."

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.

Writing down passwords

[Daniel]

I'm not sure about this being unequivacally bad. I choose my passwords via an algorithm generally known as the "bang randomly on the keys" approach, and usually *do* write them down for a day or two, until I memorize them. But while this certainly is a theoretical security problem, I don't see it as being important, because:

1) I keep them in my wallet, which is in my possession at all times
2) Even if someone stole the wallet -- no, let's be optimistic and say that someone found it lying on the sidewalk -- there's nothing marking that particular scrap of scribbled-upon paper as different from all the others I lug around; I don't label it "Super-Secret Computer Password" or anything. In addition, if the paper were lost just by itself, there's no way to know *whose* password it is, even assuming the leap in logic required to deduce that it's a password.
3) After two or three days, I tear the paper up into little bitty pieces and throw it out. Now the Evil Person not only has to figure out that this random scribbling is a password and figure out that it's *my* password, they also have to dig through the trash (which is of course mixed with all other trash from the region) and reconstruct the paper from fragments. If someone is determined and capable enough to do this, I'm not sure why they don't just install eavesdropping devices above my computer ;-)

Daniel