Slashdot Mirror
Username/Password - Is It Still Secure?
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?
Why don't you just have the patient send an email to the doctor signed with the patient's PGP key and encrypted with to the doctor's PGP key? Doctor->patient messages would work the same way. That would be more secure and not difficult to implement.
As long as there are speedy computers and brute force attacks, the username/password scheme is vunerable. Second-level passwords or phrases decrease the vunerability substantially, as long as they are arbitrary and not user-linked. (None of that 'Mothers maiden name' stuff)
What I wonder is how adding a second authentication scheme could delay the project for so long.
.sig: Now legally binding!
Secure is not a term you can throw around - you don't have a "secure" system or an "insecure" system. You can't say l/p is "secure." It's secure to a degree.
On that note, I'd say an https connection is secure enough. I'd prefer a zero-crypto verification on the client computer as well as an l/p, but I've always been an advent of zero.
My only question is why it hasn't been implemented. It doesn't provide 100% guarantee of verification, but run enough times it approaches a statistical equivalent to there being someone else using your l/p and is therefore as secure, but doesn't transfer anything which can be hashed back to the original.
On a more practical implementation, you could look for something like SideCar, etc, that implements Kerberos for a double authentication, although that would still be an l/p solution (although a different l/p, of course, providing two tiers, but that's both confusing to users and to implementation).
Why not just encrypt the email with a 128-bit key? Of course, it could get rerouted if someone was persistent enough, and perchance decrypted, but that's very secure.
*shrug* just some ideas.
So many things couldn't happen today
So many songs we forgot to play
So many dreams coming out of the blue
ls:
(A)bort, (R)etry, (I)gnore?
It sounds very fancy and secure, but the old saw about the chain being only as strong as its weakest link applies strongly here - if your retinal scan will be sent over open wires, you're still exposed to a packet sniffing / IP spoofing attack.
Just my $0.02...
"I will take the Ring," he said, "though I do not know the way."
I think that too many people are moving too fast on things like online banking and medical info online. Enough things are cracked every day/hour/minute that are "secure". There is always a way in...if someone wants to find it hard enough they would. This is not the type of info I want available to people. I would rather make an appt. and go see the doc in person. I would rather (even though it is not always easy) drive to the bank and do my business.
But that's just me...I have a buddy that uses online banking and swears by it...I just don't like it...it gives me a funny feeling.
bah
My bank uses a security-card which generates some kind of random key every time I am supposed to log in. The key-generator is like a calculator and it has a password protecting it.
So, what I do is enter my bank-account on the HTTPS and then get the "calculator" give me my password which I then enter.
The plusses with this system is that any snoopers won't get my password (new password each time) and you'll need both my bank-account-number and my handy little keygenerator (which is password-protected with my personal 4 digit pin-code).
=-kiOwA
=-kiOwA-> EOF
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.
-- Erich
Slashdot reader since 1997
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.
I've spent about eight years total in the health care industry, with about four of the last being specifically online. The company I was with recently was looking into this very possibility (as is likely every health care player). What we finally came up against was a bill in Congress (may be out by now...but I haven't heard) that extends the security provisions of the HIPPA Act of 1996. The "digital transmission of patient-specific information" likely will require use of Public Key Infrastructure (PKI). The problem there is pure cost. PKI certificates can run from $15-85 per year per user. After much searching, though, EDS seemed to be the right player to support this type of implementation.
Hope this helps...
---- Please be nice in case my Slashdot karma ~= my real life karma.
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.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Well, a few things:
1. You need to draw a distinction between offline and online attacks. Offline attacks allow the attacker to try a password without the system knowing it; this allows a brute-force attack to be carried out without detection. Any scheme where the attacker has access to the encrypted password allows offline attacks. Online attacks require interaction with the authentication server; consequently, an attacker usually only gets a few tries before being detected. ATM machines (as long as their connection to central offices are secure) are an example of a system where attacks are online; a 4-digit pin number would be trivial to brute-force (it's basically a 10-bit secret key), but because you can't mount offline attacks against it it's still fairly secure. There are password protocols that aren't vulnerable to offline attacks; SRP (The Secure Remote Password protocol), available at http://srp.stanford.edu, is an excellent example.
2. You can make offline hacking attempts arbitrarily difficult once you have out-of-band information--in SSL, you have a public key pair and hence have done a key exchange before the password needs to be entered. By sending some randomly generated per-session salt over the line you can make it much more difficult to execute an offline attack. Consult a security expert for details.
3. There's a fair amount of evidence to suggest that proactive password checkers (e.g. running "crack" against the password when it is set and rejecting "weak" passwords) doesn't buy you that much. It gets you something, but not as much as you'd expect.
Sumner
-- rage, rage against the dying of the light
Here's all you need: http://www.modssl.org/docs/2.4/ssl_howto.html#ToC6
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Aside from mathematical concerns specific to the particular implementation, the username/password concept is basically just a virtual implementation of possibly the oldest security mechanism in existance, the lock and key.
;). We should always be looking for more effective methods to provide authentication for data that requires higher levels of security.
Lock and key is nowhere near secure enough for a lot of things, like classified military data, or whatever. That determination is up to the owner of the data.
Lock and key is, however, extremely simple, and more than effective enough for a whole boatload of day to day considerations. We shouldn't be looking to replace the system altogether (until retinal scans from every terminal device become feasable
My ssh client uses passphrases and RSA keys. I'm pretty happy with this combination. Then again, I'm not dealing with highly classified data most of the time...
Anthony
^X^X
Segmentation fault (core dumped)
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
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.
--
Following up my own post...
Of course, you could give customers optional levels of security: "You may stick to a login/password, or you may pay $20 for a card reader for your PC"
--
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
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.
I would suggest that a login/password scheme is sufficient so long as you make a stringent effort to keep people from doing stupid things with their password. Run their passwords through a quick idiot check, and make a very big point of telling them that they shouldn't write it down, etc, etc. Make it clear that their privacy is at stake if they do not take proper security precautions by picking out a good password and keeping it to themselves.
Other scemes for authentication tend to be very complex to implement over a web interface. What would be really ideal is some sort of PAM like interface for browsers. So, you could write a plug-in that somebody could download that would permit the interface of a biometric device or similar. But to the best of my knowledge that doesn't exist.
---
This sig has been temporarily disconnected or is no longer in service
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."
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
One problem of any data security system that requires the user to remember a lot of data (passwords, phrases, &c.) is that users are prone to do silly things like write their passwords down and keep them in their wallets or desks.
I'm guessing that most Slashdot readers are already used to having twenty zillion different passwords, passphrases, PINs, and other secrets in memory. However, the bulk of users whom I deal with every day (I'm a sysadmin at a small college) put up quite a bit of resistance to having even one decently secure password. The office staff by and large set up Eudora to cache their mail passwords so they never have to enter them, and leave their systems unprotected. After the release of PGP 5.0 for Mac, I started an initiative to encourage them to use PGP for mail, but even with 5.0's an easy-to-use graphical interface, they didn't use it, because they didn't want to remember another bloody password. That we don't have massive intrusions of privacy going on here all the time says more about how boring it would be to read these people's email than it does about our security.
(Consider also that the two most popular desktop operating systems -- Windows and MacOS -- both now have 'keychain' systems which can cache all your passwords, protected only by a single system password, a single point of security failure.)
Currently, users don't want more passwords, and when they're required to have more passwords, they will take steps to circumvent them, thus reducing the effective security of the systems they use by some stupid factor. If we want secure systems, therefore, either we need to get the users to be as used to memorizing zillions of passwords as we computer geeks are, or else we need to start relying on something easier on the users' brains than passwords are.
Even though I hate my bank, I do like their online account system. It uses a AccountID/PIN/SecretWord system via 128-bit (required) SSL. The account ID is not my normal account number, the PIN is not my ATM card PIN, and the secret word is actually two words. This is good so no one goes dumpster diving looking for my info.
.htaccess or something, use a real world username/password and then see how long it takes a simple brute force password app to crack it. It won't take long. Then show your boss how readily accessible these tools are to anyone who can type a text tring into a search engine.
I'm pretty confident in this system even though I know a system such as this is only as reliable as the weakest link which could very well be my connection/machine/security practices. (I've already said too much already.)
I would be very worried if my personal medical records were only protected by a simple username/password prompt which can be hacked in no time by brute force.
The way to convince them is to setup a mock site and protect it with
If that's not enough, quit your job because you're working for complete idiots. *grin*
SecureID cards?
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
I've noticed alot of posts about IPSEC and SecureID (hell I even made one) but he's dealing with patients not remote clients. SecureID would be too costly to implement and IPSEC wouldn't make sense. I htink possibly distributing a client certificate on a floppy to the patient at thier first visit would work well. That way you have Certificates from the patients as well as username and password auth security. Include instructions on how to add the certificate to thier browsers and explain to them why it is important to handle it this way (personal information, privacy and what not.) Another important key is to not alientate the patients who DON'T have net access by making them feel stupid when the receptionist asks if they have internet access at home. Of course that part is just a side note. No one should feel like less of a person because they can't get online for whatever reason.
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
Pick one for them.
:-).
Put in a fairly good randomized password generator, and don't allow users to change their password.
The reason for this is if someone gets the password file. I assume you're using a one-way crypt-type function for the passwords anyway. With randomized passwords, an attack on this will take forever, because dictionary files are useless against it.
Since you're using SSL (require 128-bit too), packet sniffing is pretty useless.
Yes, it's still vulnerable to a brute force attack (everything is, really). So let the user only try 3 passwords in say, an hour or so. This makes brute force take forever, and, if the user really forgets, they only have to wait an hour or so.
Yes, you'll have problems with people forgetting passwords, but most people write down passwords anyway and keep them in a wallet or purse or some such. There is no security without physical security anyway.
If the user forgets his hard to remember password, he can call in and get it changed to something else (also randomized) after proving his identity through other means (knowing SSN, phone #, mother's pet's maiden name, whatever
Passwords CAN be secure, in that you can make getting in more trouble than it's worth to the attacker.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I agree with you that two-factor authentication is necessary for any real security. However, if you can't get that, insist at least that real password security is used, and that means using Secure Remote Password or SRP. This protocol is not patent encumbered and has an open source implementation; it provides a remote password login protocol immune to dictionary attacks, various forms of spoofing, and password equivalence problems.
I believe it is the *only* way to do networked passwords without nasty security flaws.
Also, passwords should always be subject to key stretching: see Schneier et. al., Secure Applications of Low-Entropy Keys.
SRP can be securely combined with two-factor authentication for best security. Good luck - and don't look to the banks for examples of how to do things right!
--
Xenu loves you!
One of the basic tenants of the patient/doctor relationship is confidentiality. A nurse where I work recently was posting on an online medical board and gave just enough information about a case that the patient might be identifiable. She was fired.
What happens if your employer finds out that you have a possibly terminal illness? Does this affect your promotion schedule? Do you want your neighbors to knows that you have an STD? Are you less likely to go see a doctor about awkward problems if it's possible the information might become public?
We have extensive security measures to protect information from doctors and nurses who don't require immediate access to patient data. We have an entire security subsection for employees and vip's who are admitted, so that even IS folks can't see their co-workers data.
To sum up, patient data requires more security in our environment than anything else, including payroll, billing and corporate strategy. I would probably recommend a SecureID type solution for a case like his.
If you want a secure communications media, you can make an application which comunicates trough a secure socket, but designed by you. You can use RSA, as an example and use 4096 bits keys, since you dont need a time critical application. The user sits in fron of a computer and opens the communication software then he inserts the iButton, so he has acces to the communications. The message is encrypted with RSA with the user identification (from the button) and is sent to the server. You dont need e-mail, https, ssl or anything else, you just write all the apps. When a message arrives to the serve, it replies to the corresponding Dr. Obviously, the server has to generate a pair of public and private keys when the client connects, and send the public one. The client generates a pair too, and sends the public, so everything is encrypted. And the patient doesnt have to remember anything!!! he just brings the iButton. Francisco bigjocker@yahoo.com
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Credit cards are an example of a good cracker policy. If my credit card number is stolen by a cracker who goes on a spending spree in Hong Kong, I'm out a maximum of 50 bucks.
Ask the bank what their policy is if a cracker hacks your on-line checking acct and xfers all your money to whereever. I doubt any bank's policy is comparable to that of credit card theft. Ask your HMO for their policy too. If they get tight lipped or start treating you like a would be cracker for deigning to even ask, be wary.
SSL supports the notion of client authentication. Most SSL toolkits support this, although I don't know about the SSL embedded in web browsers. The concept is simple. A client gets issued a certificate, just like any server. When they log in, your SSL can ask them for the cert and to verify themselves.
If you have a powerful enough SSL toolkit, you can setup something fairly automatic and easy. Tell your SSL to request (not require) a client cert. If the client doesn't have the cert, make them login with username/password. Then, tell them to generate a keypair and sign a certificate for them with your own private key (this can all be done with HTML). If they have a cert, check it against your own public key to see if it was one you signed (in X509 certificate parlance, you are the CA). Finally, they everything is good, let them in.
email me if you have questions: drig@noses.org
Citizens Against Plate Tectonics
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
Hurry up and jump on the individualist bandwagon!
The trick, of course, is that it assumes we can use ANY password and ANY username, and neither of those is true. If we used only words in /usr/dict/words, there's about 3e8 possibilities, and a determined cracker with a computer could process that in hours, or even minutes.
What you need to ask is "what is the value of this information"? Don't say "incalculable" or "priceless" because then any authentication scheme won't be good enough -- because you have to ask "does it cost more to find it than the information is worth"?
Banks get by with a card-number and password on retail bank web sites because usually Aunt Minnie only has $83.74 in her checking account anyway -- so no one thinks its worth trying to crack her accunt for the whole $83 it would pay them. You need to make a similar analysis for the medical information: how much is the information worth, or how much could you be sued for if it got out?
You first need to identify the security risks that you are facing and what reasonable steps you can take to address the threats you face.
Risk 1: J. Random Cracker wants to look at Grandma's urine test result, so he snoops her session or tries to impersonate her. Passwords+SSL are pretty good. If he has the wherewithal to implement a man-in-the-middle attack, he could defeat this. Pretty difficult to do. Frankly, he'd be better off doing it against her banking session because he might be able to get some real cash out of it.
But, unless he can get his hands on your encrypted password file (see risk 2) he's just going to have to guess. Some passwords are guessible. User selected passwords are especially weak, but aren't any better than good passwords that Granny has to write down to remember. Locking an acount after x incorrect guesses helps. x=3 is probably too low. x=6 might not be.
Risk 2: J. Random Cracker wants to look at everyone's lab results so he can identify HIV- women to hit on. Your server needs to be secured.
You don't store cleartext passwords. You don't install unnecessary software on the server. Ideally, you store everything on a seperate db server and pass messages between the two.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
As for security, if you must do this, you could use cross-out password lists, challenge-response with a piece of hardware, or a smartcard. My Swiss bank uses cross-out password lists. It's mostly US banks that seem to believe that security doesn't matter much.
Once they have this access, give them a choice of less secure to most secure methods of accessing their data and explain it to them. Make it clear security of their communications is their responsibility as well. Have them sign something next time they are physically at your offices.
If they are lazy they can just use u/p as they just did. Let them pick an easy to remember password if they like they can pick their damn username. They use this to login to a message center via https, make them use a 128-bit browser, you can even give one away on CD when the user comes in for a visit.
If they are more energetic, they can submit their password to a password verifier/tester that makes sure it isn't a dictionary word, 3l33t 5p3ak, or otherwise easy to guess. To help keep it easy, you could have your password generator/tester check for "pronounceable" passwords like gerpratlis, which, as far as I know, is not a word but perhaps easier to remember.
For those who want better security, support a public key system like PGP on their normal internet email systems. This system is probably great for most users. This brings up some issues, like making sure every doctor has an email address accessible to the outside world, I'll come back to this.
For the truly paranoid you have PGP messages submitted over 128-bit encrypted https to your message center.
This brings up the notion of supporting all these communication types. First let me address your users.
Well, the first two options are technically the same except at password generation/assignment time.
Users of PGP over https (the last option) have all the problems of the first two options, but you have to support PGP for those users.
Users of PGP alone (the third option) only burden you with support for PGP.
Supporting all this within your organization is perhaps easier. First make sure that all your communications are signed in PGP. If the patient uses PGP, you encrypt and sign. The difficulty comes in making sure that all your staff can easily tell whether or not their patients use PGP or not. One method would be to require PGP users to send their public key whenever communicating. This is easily enforced on users of your own "message board." Another supplementary method would be to mark all PGP using patients records with a clear code that indicates they use PGP. You could also maintain your own keyservers.
Remember the third option, you now have to be certain that your doctors can send and recieve Internet mail the same way they use the "hospital message board." If the message board is just some sort of mail repository this is easy. you can implement this by giving all https submitters an email account at your site, and then accept outgoing mail (mail from your patients and staff using your mailserver) only from your website, where patients are logged in, and from your internal machines. This approach is subject to spoofing. You can deal with that by allowing mail from the website only on direct physical connections. Similiarly connections from the hospital will only be allowed from the intranet. Users using Internet mail with PGP will have to depend on PGP only for authentication, as will the hospital.
I know this wasn't exactly the clearest posting, but I hope it can be made out.
Don't post innacurate information
If you do, I swear by my pretty floral bonnet I will end you.
Since you brought up the spectre of financial institutions' ideas on security, the following recent personal experience should provide some insight into the current state of thinking among some in the US:
I applied for life insurance with a major reputable company, and was accepted. Their typical m.o. is to set up automatic withdrawal, but I declined and wrote them a check for a full year premium (several hundred dollars). About a week later, I received a confirmation from them that they had automatically withdrawn the full amount using the account number taken off my check AND cashed my check. I immediately called to ask why they had done this, and they were gracious enough to immediately reverse the automatic withdrawal by making another unauthorized transaction to my account -- this time a deposit.
I'm a little irritated at the insurance company, but I was infuriated that my bank allowed these multiple unauthorized transactions. So I inquired further. It turns out that my bank (Washington Mutual, based in Seattle) does not know the difference between identification and authorization! Their position is that I gave authorization to the insurance company by giving them my account number, which was printed on the bottom of my check. I informed the bank that (a) in fact I had not given the number, but that it was taken from my check, and (b) that the number is identification, not authorization.
Neither of these facts fazed them one bit. In numerous calls and personal visits (I happen to be working near their headquarters), I could not find a single individual who understood that there was a difference between identification and authorization. What does this mean? IMHO, it means that there is no interest in even password-level security. Sure, they understand that when a customer looks at their account summary online they need to have a name and password, but when Joe Random fishes my check stubs out of the shredder and learns my account identity, the bank will duly process every one of his automatic withdrawal transactions without authorization. The kicker is that WAMU informed me that there is no way to refuse this type of transaction -- if I have an account with them, I *must* accept this idiotic risk. Needless to say, I'm investigating whether my credit union has a similarly brain-dead policy. (I'm afraid, however, that this may be the result of nationwide transaction policy -- perhaps even mandated by Federal Reserve rules.)
With respect to the main topic, this has some frightening implications. My bank not only allows informational access, but transactional access, without real authorization. Ok, so someone can steal money from me and my bank officially considers me to be at fault. This sort of SNAFU won't necessarily do me in. But what happens if online access to medical information takes the same route? What if I can not only inquire as to my own information, but I have transactional access as well (such as requesting medication refills, changing my ship-to-address, reporting my progress in treatment, etc etc)? This could kill me -- literally. I applaud the effort to provide strong security, and if it's offered, I'll opt into it. But right now I'm concerned about just basic authentication.
Jon
I think not...(*poof*)
If you have the cash available, I consider token systems (SecurID et al) fundamentally better than host-based systems such as ssh.
:-)
You almost always want to authenticate _people_ not machines. SSH or PGP like systems that rely on a key file that resides on a particular machine are fundamentally broken for most of the purposes they are used for. The security is there, it's the functionality that's broken. Of course SSH as an encryption feature, but I'm only speaking of authentication here.
Host-based authentication for general access is as bad as having to let your bank know which cash points you'd like to use - and then they would only let access your account from those machines.
Ideally, the public-key system used in SSH would operate from a smart card rather than an encrypted file on a hard-drive, but it will be a long time before many machines are fitted with compatible smart card readers. The systems used by SecurID are transparent technologically - I use plain ol' telnet, ftp, HTTP basic auth, Radius, whatever, and I get proper two-factor authentication based on known secret and possesed secret.
I like it. Ditch SSH and give your staff cards!
-----
I know of *no* system that solves all the problems SRP does. If you do, please give details - "other solutions have been published" isn't very informative.
Also, the key stretching paper explains why the technique described there is more appropriate than the technique you reference for passwords.
--
Xenu loves you!
Last I checked, the military prefers a three-pronged approach to verification. Simply put, you're verified by who you are, what you have, and what you know. In computer terms, this translates to:
Who you are - a biometric of some kind, usually fingerprints
What you have - a token of some kind, usually a smart card.
What you know - a passphrase
Unless all three pass, the login doesn't work. At the same time, I'm not sure you need quite that level of security. But it's something to consider.