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?
The main security hole that we are trying to cover with this type of stuff is not access to the system by the patient/doctor/user. It is the communication between the terminal/PC, the database, and the terminal/PC. For that, extra layers of passwords don't work. Some of the systems that I've worked with use a secure communication protocal of some sort, that encodes/decodes the information. Such things are probably good and right, but they shouldn't have to be the problem of the user! That is what they pay developers to take care of.
Mike Eckardt
meckardt@yahoo.nospam.com
http://www.geocities.com/meckardt
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 looked at the website and didn't find the source code...the kernel is GPL'ed, so they have to distribute the source....Did I not look hard enough? Can someone point out where the source is? I guess if it's a clean room implementation, they don't have to distribute the source, but considering how available the linux source code is, I HIGHLY doubt its clean room.
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
Username/password falls down to almost any brute force cracker (L0phtcrack etc.) Two factor security whether it's username/password + boimetrics, client certificates, proximity cards, or whatnot, should almost be considered a patient's right.
Regardless of whether or not Username/Password security is inherently outmoded, people as a rule do not use difficult to guess passwords. I run cracking programs regularly on the machines I am in charge of, and I see passwords like "123456" or "user'slastname1". You see the problem, I hope. Adding security isn't going to make you anymore popular, though. Even though it's for their own protection (speaking as someone working in a financial), people will get pissed if the authentication is more difficult or more complex for them than an ATM.
I hope this was helpful, I'm not just making up an excuse when I say I'm hungover.
-nme!
Why not just up the number of characters in both username and password, and then require that they also do the alpha-numeric thing?
That would probably bug people less than requiring one more step in the login.
But then, if I was breaking in, trying to get the value for yet another field could definitely be annoying.
It's hard enough maintining even user/passwod security schemes... What would you propose instead? Without special hardware to take DNA samples of you.... Let's get real here. Uname/PW is easy, and "Secure enough" for pretty much everything - you read every day about DES stuff getting cracked because that's teh funs stuff to crack..
Let's reverse things alittle... how secure are telephones? How secure are passwords sent via encrypted https? I'm willing to bet you money the latter is widely considered more secure than the former. Guess which one is under scrutiny. Funny, huh?
I'm not a security expert, although I do take an interest in security. My advice, given that fact, is that strong username/password combos would work well. Most people don't choose strong passwords... so your question really is "Should we care if the user(s) give away their personal information and then try to sue us?" This is more a legal question than a one of technology.
--
I'd think that Username/Password-HTTPS is secure enough for tranmissions like...
"Yes Mr. Johnson your colon is going to be just fine."
But for something like this.
"Mr. Johnson I just got the results of your tests back and you're not responding to the AZT the way we thought you would. We can't even treat your HIV."
Call me old fashioned but public key crypto is the way to go. You can go for convience or you can go for security.
Please save the "Not everyone's a geek like us, this is too hard for my poor little mom."
People who can't handle public key crypto are just as likely to leave their username/password/codeword written on a slip of paper taped to the underside of the keyboard.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
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
Anyhow, if sufficiently random passwords are used, I doubt there is much chance of someone cracking it and reading about your questions on someone's genital herpes... So in asnwer to your question, this "slashdotter" thinks username/password is more than sufficient.
Omnibus
asinus sum et eo superbio
asinus sum et eo superbio
in omnibus veritas
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
Why not use a Crypto iButton for challenge/response?
www.ibutton.com
wrong news item! my bad....
Yes, it is definitly handy... But are you sure this is so amazingly secure that you would like the whole world to know about your medical condition? sure there are those certificates thingies... HP must've sent me half a dozen of those before I could update the firmware on my printer, but still, I managed to do this without even having to put a password!
Joke aside, even if I had put a password, this is no secure http we are talking about (it's only a printer, isn't it?)... but even if it were... what exactly is encoded? the password? the web content? the cookies? Look at what happened to the bloody DVD thing!
I thing some stuff is just better off without network connectivity, or at least should be kept on an intranet... even so, I wouldn't trust paatient information unless the account itself was strongly encrypted... solaris/linux/bsd/[...] all support that, don't they?
---
"Hasta la victoria siempre!" El Comandante
With my bank, online transactions can only be done after entering your bank card number (which would technically be a username) and then there are two secret keys that I have to put in. The first is a 3 number code of my choosing, then the second is my "code word" that would identify me at any bank if i didn't have proper ID. So basically there is one username, and two passwords.
Using secure sockets would help, but it's easy enough to implement a second password type deal, and that would just give you that little extra security.
It's never going to be totally secure, because people are involved, but you can take precautions to help make it that little more secure.
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, as a potential user of such a system, am much more concerned about what happens to the information on the server (i.e. your) end. I don't know who the operators are, how my data is handled, and who's reading it. That worries me much more than someone trying to crack my username/passphrase.
I'm not sure additional layers of authentication (beyond username/password) are necessary. I would, however, assign passwords/phrases to users, rather than letting them pick their own, to keep Joe Slobot from picking 12345 as his p/w.
As an aside, expending so much effort to ensure privacy here seems like a moot point - anyone with health insurance in the USA basically signs away all privacy righs, where their medical records are concerned - it's boilerplate on every application of every insurer in the country, and one has no control over this data once it's in their hands.
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
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
why not simply phone your GP up, or make an appointment?
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
Look at the OPUS project done by my advisor, Gene Spafford. Consider the kinds of passwords that people use based upon the research--they're abominal!
First Issue:
Is it possible for someone to steal someone's username and password online or without having direct access to the vitim's personal information?
Answer: Probably not, although that depends on the individual. My guess is that nobody would hack someones personal system to get that type of information. However if this did happen, I'd consider this equivalent to invading someones home to get this information.
Second Issue:
Is it possible for the victim's password to be brute forced?
Answer: Depends. If the password can be brute forced without accessing the website, then you've got serious problems. However if the password needs to be brute forced by accessing the server, then so long as you have some type of cut-off for how many guesses the attacker can make, then I really don't see a problem with it.
Have you considered cutting a deal with Hushmail (http://www.hushmail.com)?
They are a web-based e-mail system which uses 1024-bit encryption which, because it uses a Java encryption applet at the client end, is end-to-end secure (even Hushmail can't read your mail). This would perhaps avoid you having to use the "paging" style kluge whereby doctors are sent insecure e-mail to inform them that secure e-mail is waiting for them, and you'd get a lot of the security/maintenance stuff for free.
If you were a big organisation, you could even license the technology and run your own version of it.
Note that Hushmail accounts are protected by a username and passphrase. They seem to think that's sufficient.
Gerv
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
This is the same as the USGov/Privacy issue. Any information you have can be accessed by anyone, if given enough time and resources. If someone wants to listen to every conversation you have, they CAN, given enough resources.
Its the same as the infinite monkeys writing works of Shakespeare; ANYTHING is possible in infinite time, or possible in finite time with infinite resources... (And much satisfaction was gained by comparing the NSA to a bunch of feces-throwing hairy tree-climbers)
You need to compare the difficulty needed to put this security scheme in place (years, apparently) to the benefit gained for the security. Is it going to stop someone dedicated to finding this information: No, in both cases. Is there anyone who would be able to gain access to the information with the pasword security scheme which would NOT be able to gain access with the two-factor scheme?
I think this might be able to stop someone randomly searching for saleable data, but how many such people are going to look at a medical database for that sort of information? There are easier ways to get more profitable information, I would say (not to mention the ease of physically getting access to the patient's files).
>>>>>>>>> Kvort
-Don't mind me, I'm personality-deficient and mentally-impaired.
I'd shoot for a fingerprint identifier ($100) and/or retinal scanner. This tells people outright they need to buy equipment to do this, because your company is dead-set on protecting their privacy. Use that as a selling point.
The way this is set up to begin with is a pain in the ass. Why not just send e-mails to each other? Why even hassle with the online stuff? If you digitally sign e-mail, it isn't THAT insecure. Heck, digitally sign it AND encrypt it.
In the event you won't simplify things and make life easy, two logins are a good idea. Unfortunately, you need to remember both, in the right order, to be identified. It's a bit of a strech to assume each person can handle doing this on their own, especially when you throw in that they possibly need to remember their login to the Internet and login to e-mail system. You need four pieces of identification to ask your doctor if he got the test results back!
-Doug
Winners tell stories while losers yell deal.
I think the biggest problem with the user/pass scheme is the user him/herself. Anytime your security scheme is dependant on the user, you are vulnerable. We all remember the recent DVD DeCSS crack, broken because the people over at Xing were sloppy.
I work for a College and when I want to access the accounting and/or grades systems I have to enter username/password and then I get a challenge number. I enter the 8 digit challenge number into the cryptocard (remember creditcardcalculators, it's like that) and it gives me an 8 digit response number to enter and voila, I have access.
I have no idea how this stands compared to PGP but it seems very secure in that if someone gets the card they don't have my user/pass and if they get the user/pass they don't have the card, unless of course they torture me, but I could probably be bought real cheap.
"Share your knowledge. It's a way to achieve immortality." -- Dalai Lama
What about distributing "key" files? If you give each user an encrypted, signed file holding their user info, and require them to upload that file at every login, you would have a pretty good security model.
A cracker would have to know a username, a password, and have access to the user's key file to gain access. That would be more secure than a simple username/password setup. If the entire transaction (including the transfer of the key file) is done via secure HTTP, it should be very difficult to gain unauthorized access to the system without having physical access to the user's computer.
0 1 - just my two bits
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
Let's face it username/password can be quite secure and quite unsecure. It's all in how you use it. If the password is sent via an encrypted link, or a challenge response system, it is as secure as the underlying transport and the entropy in the password.
Under Unix we have historically had an 8 character limit on passwords. This was due to the underlying implementation, and did lesson security under a number of situations. Now we can use a more generic hash algorithm rather then a bastardized DES, and this allows for much longer passwords. If I have a mixed case alpha numeric password with n characters that is 62 choose n. Take out a calculator, your not going to have a 10 to 15 character password brute forced without noticing it. Offline attacks can be even more fouled by salt.
As with almost all security applications, it not the underlying technology, but how you use it.
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*
If you were keeping complete medical histories I would have a real problem with this. However, its only going to be messages. Assuming you delete the messages after a reasonable time frame...say 5 days (the user can, of course, save the message to their machine before this) and you make them pick decent passwords (plenty of discussion on this before) I would think it would be fine.
Perhaps get the system up and then work on version 2 that allows more security for those who want it? Preston
This topic is way outside my area of competence, but -- reading the comments, it looks like people have widely divergent concerns about what the threat is from. Is it crackers/kiddies trying to break in and disrupt things, with no interest in the data itself? Is it somebody looking for information on a specific person? Is it an insurer or marketer trying to build a database on your patients?
It seems to me that where you concentrate the most effort on your defenses depends on which threat you consider most significant.
What I'm listening to now on Pandora...
I'd be VERY suspicious towards a site with personal information such as medical records or banking information that didn't use some kind of one-time authentication like SecurID (http://www.securitydynamics.com/products/), HTTPS and the works. Maybe I'm paranoid, but better safe than sorry.
I think login/password is fine, as long as you have a good password.
I learned this when the other day one of my CS professors emailed me to inform me that he had cracked my password on our SGI cluster, as well as the passwords of several other students, who were using dictionary based passwords. Needless to say, I've changed it to something non-dictionary based. I had never thought someone on our small campus which is protected with a firewall would even try to break in to my account. Naivete is definitely an issue in security.
If you've got a non-dictionary based password that's one step. Another step is always use encryption - I always log into hosts on campus via ssh, and never share credit card info online unless the server has some kind of good encryption.
I have used BankBoston's HomeLink web banking in the past, and they required you to use a 128-bit encrypting browser. Has a 128-bit encryption scheme been cracked yet? I know that the RC5-64 bit encryption was cracked...
And of course making sure that your system/the system you're working with uses shadowed passwords is another level of protection.
But in the final analysis, I'd say that whenever you can log in to something, it can most likely be cracked. It might take some extra effort by the cracker, but if they want it badly enough they'll take the time to do it right.
-P
I was just discussing this with an attorney in regards to setting up a website. You can't depend on a typical user using PGP (many can't even spell PGP). He did suggest a form via https, but then it will not be secure, but it will be on the server unencrypted until the process encrypts and emails it.
I suggested a java applet, that will encrypt the data before sending it to the server. Then the server can send it to the lawyer.
There is no absolute security, but you have to balance the ease of access to the security of the data.
Injured geek wins against Mattel!
The easiest point of attack of your security scheme occurs server-side. I would guess patient data is streaming clear text on the server. Patient data integrity would require the communication channel to be encrypted between the .app and server.
Get this platform deployed, secure the channels in subsequent upgrades. You'll learn a lot more this way than trying to get it right the first time.
The more systems we have with unique user names and passwords the more likely we are to do things that weaken them.
One user name and password I can remember and even keep my password pretty random. If I have 15 to 30 user names and passwords I an going to have a hard time remembering them and am going to either start writing them down, start reusing them between systems or start making the password a simple function of the site/username. Another problem is the frequency of use a username/password is easily forgotton if not written down or used regularly.
To avoid some of these problems I make use once accounts on any sites that require the establishing of a user name and password (except slashdot, but my slashdot password is now my Novel network password (example of evil creep), and I allow the slashdot cookie to continue to exist).
As another example of evil creep I have two bank card passwords, one is the reverse of the other. Nothing is written down, the numbers are random and I can remember it but it does weaken the system.
Another source of weakening is that not all accounts need the same level of protection. I might feel like sharing my Gas card password with someone but not my banking password. If in the name of conveinience I have made the two passwords the same I could be in trouble.
The medical password system is a problem. I don't see it as an everyday use thing. Almost no one is going to remember a password they use every 2-6 months unless they either right it down or make it a very simple association.
Making medical records available is nice. I would prefer if they were only available at definite physical locations like doctors offices or hospitals where the information already must be made available. In these locations a staff person could authenticate the users identity using regular id and then grant access to the record.
Maybe secure record access could be extended to libraries. (libraries need to become more involved with the net) Rather than release information to the wilds of the net a library would allow a staff member check physical id. I see a two part access system, staff and user, with limited physical availability and of course a log file.
Problem: RFC2617 (the latest specification of Digest authentication) has only been out for a few months, and I doubt any of the current versions of popular browsers fully implement it.
I could be wrong, but I don't think anyone would go through a lot of trouble to crack and decode the conversations between patients and their doctors. The potential risk (risk of getting caught, and potential punishment) will be similar to the risk when breaking into a bank's system, while the potential reward seems to me to be minute. No financial reward I can think of, and 37337 d00d5 will not exactly impress their friends by revealing that mrs Jones is suffering from a nasty headache.
Whatever scheme is chosen, I think it might be more important to make it easy to understand and use for the customers, than it is to make it absolutely secure.
-----
paswords are fine, but for this level, you should AUTOMATICLY send a letter via snail mail whenever a password fails that is not followed imeidatly by a success. (that is two failures in a row get the letter as does on fail and no tries for 10 minutes. The user could enter the password wrong once, but should twice in a row)
On the form letter state "On xx-xx-xx (date) somebody from the ip address yyy.yyy.yyy.yyy [which maps to ggg.company.net], tried to access your records, and failed the password. If you did not make a mistake then someone else could be trying to invade your privacy. There have been n tries today [m this week][o this month][p this year] and a total of c attempts since you have been around. If you are concerned about this please call us at (aaa)aaa-aaaa"
I'm sure you can word that better then I did. Make sure some security expert is avaiable at that number. this letter isn't really secure, but it goes by a different route, and interfering with mail is a federal crime (in the US) which at the very least gives lawyers something more to work with if there really is an attack.
combine the letter with a 3 max tries per day (Consider it 3 tries if they get in or not, I don't know if someone needs to talk to their doctor more often though), expiring, and good passwords and you should be alrite.
Yikes! I work for the Canadian Health Care system, and a large (4 1/2 hospitals) IT department. If such a system was proposed here, we'd laugh the person suggesting it out the door. The security there is very weak, and the access to potental patient info is *VERY* scary.
We have a system to give Lab results to HIV tests on the Web. The following rules apply to it.
Login is via SSL with a username that is the recipt number on the lab test the patient is given after the blood sample is taken. The password is given to the patient over the phone(special number, and requires an identity check), and TWO pieces of identity are asked that don't appear on the recipt. None of this is attached to names, etc...
Once logged in the Person can check the Lab result, but it also carefully doesn't indicate anything that could be used to identify a individual.
Even with all this security, and the germainization(is that a real word?) of the data, this is viewed by our IT dept, as a HUGE security risk, to the point we have had the Senior Management sign-off on the system.
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"
Security is not and never was a yes/no question. Without extreme measures to make data exchange more trouble than it's worth, focus on what the policy is on hacked accounts and who is responsible and to what extent for what the cracker does. e.g., if my credit card number is snarfed, I'm out no more than $50 bucks.
Retinal scanners? DNA scanners? This is such a simple question with a simple answer. The obvious answer is something like a SecurID card from Security Dynamics (or any similar product - I've nothing to do with this company). It's easy to implement, simple to use, and as secure as you're going to get without severely annoying your customers and incurring unnecessary cost. You mail them the card, the passcode changes every minute (possibly with a keyed in PIN on the card) and that's that. As easy to implement as username/password and far more secure. I'm surprised at some of the nonsense I'm reading here.
Currently it looks to me as though there are 2 classes of users in this system - patients and doctors - although they appear to be basically be treated the same.
Although the numbers of doctors is relatively limited, the number of patients is presumably huge and relatively uncontrolled. In this case a 2 factor or token based authentication for the patients would appear infeasible - you are talking thousands of tokens here at a cost of 10's of dollars each. Additionally the patients are less of a compromise risk in that if you crack a patients account you only see the patients personal data. However the lesser number of doctors see personal data from lots of patients.
That makes me think that the patient end should be basically password driven (with a few wrinkles maybe, but not requiring additional hardware per patient). However the doctors end should have 2 factor authentication - and from my own experience of programming with SecurID I can't see why that would add more than a few days to the software design time.
A bigger issue is probably forcing logouts of users - an open window from a previous session is probably the biggest risk...
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.
- The security of the data during transmission
- The Authentication of the end-users
While the former can be dealt with by using SSL connections, the authentication part remains the most important security issue.Using two factor authentication solves this problem quickly, and contrary to the poster's expectation, it doesn't set back projects 2-3 years. In fact, it usually accelerates them because all of the password management functionality is taken care of. No need to check for "easy" passwords, no need for "difficult" passwords.
If you look at RSA Security SecurID products, you'll see how it can be used to authenticate users with one time passphrases, making cracking tools, brute force and even sniffing attempts useless.
I've had the opportunity to install these servers in Banks and government agencies and know firsthand of the relief they have since they don't have to always worry about password exchange (most employees keep their password on sticky notes) between employees.
--
Let's not all suck at the same time please
Let's not all suck at the same time please
In Switzerland (yes, that's where the cheese,
chocolate and the iKnifes come from) all the
banks I know use the following system:
https (128bit)
A username
A (user chosen) passwort
A one-time-pad
The one-time-pad is basically a list of 100
numbers (4-6 digits).
If you reach number 80 you get sent a new list by the bank.
The one-time-pad is a minimum hassle for the user
and makes the hole thing a lot more secure.
- Andreas
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!
Passwords a.k.a. weak authentication are by no means a good way of authentication in a modern system. Why are they so prevalent? Because they're relatively easy to use. We use them everywhere (i.e. PIN numbers).
If you want a better system with strong authentication you need to setup an infrastructure to support it and one that is easy enough for even non-computer literate people to understand. I like things like the iButton (for more non-computer literate) and s/key generator but you definitely have to pay an upfront cost to get the system up and the hardware distributed to the users.
Security is never absolute. Period.
The more secure a system is the less user-friendly a system is. I don't want to have a retinal scan to use my gas charge card - it's just not worth it to me.
Also, I defy anyone to not give over their password/code-phrase/hand-print if some nut has a gun held to their spouse/child's head. If someone wants to get at anything in the world, all they have to do is be willing to sacrifice their life. Big deal.
Given that I am of little consequence in this world - I doubt anyone one of you knows me, I think the risk that my medical records will be the target of some well-funded person or persons bent on gathering my innermost details of my blood pressure is very low .
That's not to say that there shouldn't be some security, but it always needs to be balanced with the costs. An on-line medical system has enormous benefits, and while I want some security, I think the system of multiple emails is too much for me to want to use.
I like charge cards. So long as I don't report it stolen, I can use it very easily and conveniently. It's 'read' at thousands of places on the globe and works wonderfully most of the time. Working at a Bank I know that they have advanced systems to track fraud or other misuse.
If I had my Medical Insurance card so programmed, then I could 'swipe' it at the doctors office and they could get access to anything I had. If I needed my records on me, make it a smart card that I gave to them when I arrived, and took with me when I left. I could have numerous backup devices at my home under any level of security I wanted.
The web is now far more secure than mail and the phone which does far more business and carries as much sensitive data as this article talks about. Let it be and move on to something else.
As a pretty typical power user, I can tell you I have a LOT of logins in a lot of different places. It is impossible to make up unique username/password combinations for each and every login and still remember them all, and we all know not to go writing them all down in a ".pass" file...:)
My solution, which is far from perfect, has been to divide sites into catagories based apon security, and use the same passwords (or sets of passwords) across the board in each security level. While having different "high", "medium" and "low" security passwords prevents some stupid web site admin from acessing my eTrade account while allowing me to remember my passwords, it's still nowhere near as safe as the username/password paradigm promises.
I definitely advocate a new approach to security. However, if I could tell you what that should be, I would have been the one to buy Slashdot...:)
http://kered.org
Authentication in the real world today generally means Social Security Numbers. If you hand over an SSN, you can find out just about anything you want to know on someone's medical or bank records. The really sophisticated places might want to know your mother's maiden name or something.
Nearly anything is better than an SSN-based security system, even vanilla HTTP usernames and passwords. I would be frankly grateful to learn that my doctor was doing something like this. Obviously banks should be using real crypto, since financial institutions are much more likely to attract sniffers, but I'm unconvinced that hospitals need the same level of security.
That said, it seems like layering this on top of SSL should not be particularly difficult, and obviously makes the transaction much safer. The world is growing larger; while sniffers and crackers are unlikely to go after medical data today, it's unclear what the black market will pay for a year from now.
You're grabbing medical records from unsecure places (like doctors offices and homes)? They'll have their password written on a post-it next to the monitor, trust me.
.02.
Some type of token based key is probably the best bet.
To cement the argument...all the way back to Firewalls and Internet Security : Repelling the Wily Hacker , username / password security has been noted to be insecure. It's *convenient,* but convenience has no place in a secure network unless you're spending big money on, say, smart cards or token based security. Or biometrics.
Just another
A shiny penny to everyone who said that the major problem here is on the user end. There's no need to implement expensive, commercial propucts like retinal scanners or iButtons. Using SSL and even something as basic as well-implemented .htaccess (i.e., "well-implemented" meaning not storing your .passwords in a publicly readable directory), the weak link is always the user-selected password. So, either 1) force the user to use a "passphrase" (and really FORCE it-- not just say "hey, use a passphrase." Reject anything less than 7 words, or somesuch thing) or 2) issue each user a passphrase. It'd be elementary to set up a script that would, for example, choose a 4 or 5 word sample from, say, the Guttenberg Project(some 1500 works of english lit.) and issue it to the user as his/her passphrase. Sure, there'd be a set "dictionary" of phrases to be used in a brute-force attack, but if the passphrase was an arbirtrary number of words between, for example, 4 and 9, and case-sensitive, with the possibility that the passphrase-issuing-script might alter captilization, then it would still be an intractable cracking problem.
Again, just my 2-cents.
-"S"HM
Much Love,
"S"HM
*****
(I refuse to spellcheck out of contempt for your belief system)
While this isn't directly on topic, it might be a good idea to check out some of the legislation dealing with subscriber privacy going into effect soon. While may or may not affect you, it's probably worth a skim, especially if you're going to be sending user-identifiable information out of the organization. I know there are some hefty fines for non-compliance. At least you could maybe back up some of your paranoia with some legal documents. 8^)
Its the law. Very strict regulations on how patient data can be sent.
1.) Inexpensive but more steps - PGP.
2.) More expensive but a little easier to use - SmartCards. SmartCards are easy and a new code changes frequently.
You still have to make sure your remote people are connecting using an encrypted session.
Or not. Because, in this case, the communication is between doctor and patient, they may only need to track the doctor's access to the records. Because (theoretically) the doctor is communicating directly with you, there may not be as stringent controls on that transmission. (IANAL.)
Why don't banks (and this medical site) use X.509 certs? Because they are a pain in the ass. Sure, they work great, but the general public has enough trouble just using a browser, much less dealing with a cert (I know, the cert is easy to use, but so is the browser!).
Right this very minute, I'm trying to set up a mini-PKI to demo to an oil company and it's a royal hassle. PKI products don't talk to your Enterprise apps... they don't follow published standards... or they implement different options of those standard and can't talk. That's if you get them to run in the first place (grrrr... I've been here 3 hours trying to get Netscape's LDAP to run on Slowlaris). These are just the server-side hassles.
Now add in the clueless clients. Not only do they have to follow the procedure to download a cert (good luck making it simple enough), but they have to password protect it (oh no, another password!). If they use Internet Exploder, they have several options: no password (what's the point?) or increasing levels of annoying password re-prompting. It sucks.
The only companies I've been able to get to adopt X.509 certs are those who are really paranoid, technically enlightened, or those who we can threaten with IT audit "findings" if they don't (those finding may be reported to the SEC if there is some kind of stock-affecting trouble).
Unfortunately, to depend on DNA for security would mean that you'd have to ensure that you never lost hair, skin cells or bodily fluids. Whoops! There goes your identity! DNA samples could only work in a controlled environment, and even then...
I see over and over again that "stupid people might write down their passwords". In an ideal world you could remember the 14 different strong passwords that you have. But it is not an ideal world, and I think most people *should* write down their passwords. It will allow them to make better choices of passwords than they would normally pick.
They should not keep their passwords right next to their computer on their desk at work, or in their wallet.
If we compare to the lock/key paradigm, this is the same as saying don't leave your keys in the ignition or under the car seat. But having a car key is still better security than most people would think up on their own. You have an increase in security, but with that is an associated need to secure the key.
I'm saying you don't get rid of the physical key (the written password) you just keep track of it and it allows your security to be better.
Yes, several thousand terabytes is slightly expensive, but it's nothing when compared to unlimited fraud potential.
Anyone remember that (bogus) story awhile back about bio-RAM that could store hundreds of terabytes of data? Tee hee. That has some neato ramifications if you ask me.
Mike
I suppose it is mildly different, but rather than getting your panties in a bunch over a single username / password pair, why not try worrying about a 4 digit PIN on all your ATM cards?
Sure they deactive after (3) failed attempts - there's nothing to say that a digital account can't do that same thing.
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.
Disclaimer: I work for Entrust Technologies, and we deal with these sorts of problems every day.
For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).
Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.
You state that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.
Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.
Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.
I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:
- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very tiny 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)
- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.
- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.
Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.
Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.
Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.
"Tomorrow's forecast: a few sprinkles of genius with a chance of doom!" - Stewie Griffin
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
But I think we should be using retinal scans or palm prints by now. It may cost a lot but for such personal and important info I'd be willing to pay the bucks. I think I'm gonna stick with physical banks and doctors for now, however.
If you think you know what the hell is really going on you're probably full of shit.
If you think you know what the hell is really going on you're probably full of shit.
jdube is who I am.
blah
Hey, why not use the DVD encryption? It is, as we all know, protected by a large hoard of raging lawyers, so nobody will be able to crack it without being sued out of existance!
-
__
Comment submitted. There will be a delay before you understand what you posted.
One thing before I get started.. This type of application as it potentially contains medical data will fall under "HIPAA: Security and Electronic Signature Standard" which goes into effect January 1st of 2000. You will want to look that over and check to make sure this system complies. The text of the regulation is available at the Federal Register.
As to your question, usename/passwords can be considered "reasonably secure" if you have proper controls on them. If passwords lock after three bad attempts, if there are some controls on password content, etc., then they can probably be relied upon to a resonable degree. What you need to do is talk to your organizations legal department, and find out from them what the potential legal cost of a breech would cost the organization. Take those figures to your boss. Implementing a two-factor authentication scheme isn't very difficult, it would be somewhat costly depending on your user base however (most hard tokens generally are in the neighborhood of 30-50 each). Both Security Dynamics and Vasco (the two token vendors I'm most familiar with) use simple Radius TACACS+ servers with the tokens. Securing a web site with those protocols is fairly trivial. (Apache and IIS have plugins for this I believe)
Going outside of your question a bit, a better solution entirely would be to setup a PKI system. The interface for your application sounds a bit clunky and could be avoided with S-MIME. Most commercial PKI packages have evolved to the point where an implementation like this wouldn't be overly complex. An automated registration authority could issue certificates to your customers easily enough, enabling dual authentication and non-repudiation / data integrity. It could also turn your solution into an email based one, skipping the work-around you have done with the web front-end. For a less comprehensive solution, albeit an even more simple one, you could purchase certificates from a vendor such as Verisign for your doctors. The web front end could be used by customers who would receive the responses via S-MIME from the doctors.
Hope this helped at least a little.
P.S. Any misspellings or faults of grammar you think you detect are mearly transmition errors, and probably your fault a
Use SSL client certificates. Each user should be issued one, as well as a random password. So, you get browser-server authentication and user-server authentication. An outside cert authority should be able to help you create them. Though, depending on the number of possible users, I would suggest looking into using OpenSSL to set up your own certificate authority. Since clients would need to load up thier client certificate, adding the extra steps to have them accept your CA as valid would not add to the complexity much. I consider running your own CA more secure than using an outside source for most applications, but the extra work may not be worth it to you.
As I recall "SSLVerifyClient 2" in httpd.conf for Apache+SSL forces clients to send a valid client X.509 cert before being allowed access. "SSLVerifyClient require" is the directive for Mod_SSL.
-Paul
"Life is life." --Laibach
Anyone designing/reviewing an authenticeation scheme, should start with reading basic background info, like Pr udent engineering practice for cryptographic protocols" and related papers.
Once you have set up your design, review it, using proper tools for authentication logic. Start with BA N logic. Although old, it will catch most serious glitches. Then consider using some of the more complex tools available, like GNY.
Even the most sophisticated ciphers won't help if your protocol design is flawed. (original Kerberos was vulnerable to replay attacks). A clean protocol does not have to be complex. The wide mouthed frog protocol only uses three messages.
Remember freshness. A l/p scheme should at least have some form of challenge/response funcionality added to it. This does not have to be visible (add complexity) to the user. See a simple c/r scheme used by PHPlib (check the source).
Ok, I trailed off from the question, but anyone interested in authentication, and haven't already read academic papers on the subject, should check out the works of Burrows and friends.
- eivindMaybe with a little automating for the user SSH would be a viable option?
Hi, I suggest you actually PROVE to them how vulnerable it is. Some people are just stubborn until you actually show them - "Seeing is believing". Gee, why not hack one of the people's accounts that called you paranoid - THEN WE'LL SEE WHO IS REALLY PARANOID. Newbie users don't understand the inherent insecurities of the Internet and the possible major problems that it could bring and they are only want to make money. They must be shown otherwise! Ignorance is futile!
First, the goal of security in general is to make it more difficult to get at an item than someone is willing to pay.
If this is *STRICTLY* a communications system between the doctors and the patients *AND* messages are not stored in a long term manner, I would guess that the most value that could be gained is by media accessing information about famous people. This would probably be million to 10 million dollar information. (You might do your own analysis of this.)
Many people like potential employers would probably love to get the information, but would not want to be implicated in such illegalities. However, you will probably see a lot of probing hackers, much of the information could easily be used to extort money out of clients.
For a more secure plan, I would consider all of the following:
1. A username/password pair with password complexity checks.
2. SSL encryption, otherwise the passwords can be sniffed.
3. Record the IP address, browser details, etc and watch for changes that could indicate a break in.
4. Store a secondary password/authenticator in a cookie, yes it's insecure, but it raises the barrier for password guessers.
5. Consider using the iButton for authentication, especially for the doctors.
6. Depending on the users, with the small amount of information being sent I would consider sending each of the users a CD filled with random information with the same random information stored on one of your internal servers for use as a one-time-pad with a Java application that would encrypt the messages with the one-time-pad. If anyone sends 720 megs of messages, send them a new CD.
7. Consider using smart cards for authentication.
8. Consider your internal network configuration, it is much more likely that a forgotten service, misconfigured router, or vulnerable service could be used to gain access than evesdropping and cracking of your communications protocol.
9. Consider the following server scheme:
A. One server for the SSL communication with the end user. It is connected to the net with an ethernet card.
B. Another server connected via a second ethernet, serial, parallel, or something else unconventional. It is logged into the first system and it actually does the processing, but it does not allow network access, it configured as a client.
C. A third system that system B is also connected to, this system is only connected to system B and it handles the encryption/decryption.
10. Consider forcing the doctors to use a specified list of computers, only allow login from those IP addresses and make sure your router is configured against IP spoofing.
You should also read:
Mailing lists: Risks, Bugtraq
Books: Secure Computing by Summers,
Applied Cryptography by Schneier
I appologize for the long post. Security is vitally important, make *SURE* you understand all of the implications of your decisions.
As stated, I believe that a secondary means of authentication is legally required by personnel when transmitting sensitive information. This can be keycard, biometrics, or whatever. The HIPAA requirements will be very gradually enforced, in order to give health organizations time to tackle the often massive changes needed to make their systems HIPAA-compliant.
Regarding someone's remark about sending biometric information unencrypted: That would definitely be a stupid use of biometrics; sending authentication information in the clear is a violation of HIPAA standards. Biometrics does not obviate the need for a basic encryption infrastructure, whether it is built on PKI, Kerb V, or whatever. It would probably be a secondary mechanism on top of cards or passwords, with information sent only after symmetric-encryption communication has been established. I don't think biometrics can be used as a sole means of authentication.
Some of my coworkers were examining the encrypted E-mail problem for a more managable set of users -- medical personnel only, for several hospitals. One law, I think also part of HIPAA, states that the IS departments cannot manage be the central key authorities; these have to be run by a third party. We looked at PGP, and we looked at the SMIME variants. The latter, IIRC, suffers from from a recent Netscape/Microsoft implementation divergence making the one's keys incompatible with the other's (how surprising!). I think it was a hassle finding a vendor who wanted to manage PGP private keys for our heterogeneous systems (different browsers, several different platforms). Then you have the doctors to deal with, who do not take kindly to any added complexity to the system, no matter how minor. It is difficult to force them to use a new tool that provides no perceptible benefit to them.
You should definitely make sure that you know precisely what the legal requirements of your company are, and approximately when these requirements will be enforced. Make them aware of the laws and they will be more responsive to your proposals.
If my 'lrge health organization' tried this they would find themselves short a customer probably more. I do not want my medical records out on the NET. I have successfully sued 3 organizations for improperly handling private records and made quite a sum on it...I would be happy to SUE the SHIT out of KAISER if they tried somthing this F'n stupid and shortsighted...Medical records are private and confidential if you cannot assure that they stay that way prepare for litigation... By the way I successfully sued a LARGE BANK for providing a social security number and received $25,000. It is almost gone now I couls use an ifusion of cash :)
Hmm, my two banks only require you to enter your social security number and your ATM pin code. :-) 4 digits, no alpha characters. I assume pretty easy to crack. Not that I care if someone can see my bank statement.. you can't do funds transfers or anything useful on the stupid systems. :-) Personally I think banks should supply securid cards to all their web customers and force them to you 128-bit SSL, but that isn't going to happen. Customers want convenience.
Even if the encryption is unbreakable, you're assuming the computer you are using is secure. But PCs are *incredibly* insecure environments. It wouldn't be impossible to steal thousands or even millions of usernames and passwords, given the "security" of today's PC's. By doing this, one could, at least theoretically, destabilize the entire economy if it is ultimately dependent on PC username/password combinations... (Roughly) how to do it: 1. Write a virus that propagates itself around the net faster than virus hunters can find it. This depends a lot on doing really well at hiding the virus. ActiveX/JavaScript security holes could really help too. Imagine how fast a virus could spread if it were hacked into a commonly used portal, for example... 2. Attach a payload to the virus which hooks the password dialogs of various apps like IE, Netscape and specific financial packages. 3. Make the virus really smart about hiding. Have it unhook whenever system tools are used. Have the virus disappear entirely if it detects a debug or developer kind of environment. Make sure that the virus detects tools and techniques that might be used to detect viruses. Just making the virus smart enough to hide completely for a day or two may be enough. 4. Hook the system and piggyback the data logged by the virus on outgoing packets that won't raise eyebrows. By hooking tcp/ip or browser code, one could theoretically get the data out on vanilla HTTP request packets as the user used his browser... 5. Time the virus so that nothing appears to happen until a coordinated date/time (probably just a few days after the virus is released) so that there's very little time for anyone to react. I have no idea what step 6 would be because I wouldn't personally want all this data, but I'm quite sure that it's theoretically possible to get it. And I'm not even a virus specialist. Just a run-of-the-mill systems programmer... I worry very much about the above class of scenarios. If you think about it, the scariest part of it is that saying "don't worry, it hasn't happened yet" doesn't mean much at all. If it was done *really well*... MAYBE IT ALREADY HAS happened!
In the United States - doctors are mandated to provide the best patient security available. They are bound by the patient doctor confidentiality contract. Its an oath. If you are worried about the doctors well-being, i think they are pretty safe. Having a simple unsecure login and passwords is an attempt to secure patient information. Its not like the doc is giving out patient information from his mouth, just making the lives of his patients easier. He will win in court 10:1, and '1' being a complete idiot of a person who deserves a punishment. And - we cant forget that if someone wants around a security system - eventually with pepsi filled nights they will acheive their goal. It is hard for medical institutions to update security measuers as really - computers produce no new income.
When designing a secured system the designer has to identify the threats and the cost such threats might impose upon the system.
The next step is to find the counter measures and to estimate the cost of implementing them. Then, if the cost of each counter measure can be justified compared to the potential cost of the damage that the corresponding threat might impose, then the counter measure should be implemented. In this case the general secured web application has a lot of threats like dictionary attacks against weak passwords etc.
IMHO the most dangerous threat to the general secured web application today, is the very serious threat coming from a netbus or back orifice attack on the client side. Using such a program it would be very easy to fetch any passwords that are entered through the keyboard.
A very good counter measure for those types of attacks are to use some kind of hardware token, be it a smart card, usb token, one time password generator or a challenge response token. Using the right tools, implementing such a counter measure shouldn't take that much time.
(See the HTTP specification for more details).
What this means is that it is trivial to recover the password if intercepted.
There is a potentially useful solution called digest authentication, although I'm not aware of any browsers in common use which support it.
In a standard server/browser situation, you will need to use SSL to provide any useful security.
For strong authentication, you can also at ActivCard (the company I am working for). They have one time password solution using hardware tokens or smartcards (X9.9 or synchronous password). Another feature with the smartcard is to store the certificate (and the private key) in the smartcard. It is then possible to do HTTPS with Netscape (through PKCS#11) or IE (through Microsoft CAPI). To use your certificate, you need to provide your PIN code and the smartcard. My $0.02
until someone breaks in and gets off with the password file.
Until an employ resigns and remembers everyones passwords.
You can't change the passwords of 20000 users. You could patch the hole they a cracker got in through, but that would be too late - the file is out there on their lame IRC channels. You could expect users to have VERY secure passwords.. why can't I just type my username backwards? you're being over the top!
No. you would at least need some other information to authenticate.
Perhaps you could use cookies that are granted on account generation.
Instead of hacking patients info, they'll just buy it from you, and isn't THAT the problem?? What good is secure transaction of patient/doctor conversations if it's easy to get a hold of people's medical records (ask any insurance company how easy it is!).
Your situation sounds like you might do well to look into SecureID tokens from RSA Data Security. I recently had the opportunity to hear what RSA is doing these days, and one of the examples they had for implimentation seems like it would fill both your needs, and the companies.
The basic idea is this: The paitent has a token, which every 60 seconds, generates a random number. I cannot recall how long said number is, but it's over 8, I'm sure. This, paired with a PIN number that the paitent knows, are what is entered in the password prompt. On the server side, the server running the RSA app has a copy of the RND seed in the token the paitent has. It keeps the same interval that the token does. (For those worring about the token getting out of synch, RSA has a rather niffty way to deal with this.) Then, when the server see a login attempt, it compares what is coming in, from the password box the user filled in, with it's copy of the seed, factors in the PIN given, and if the results match, access is granted. Simple two factor security. It combines something the paitent knows, the PIN, with something the paitent has, the token.
Heart, Hands, Honour
My opionion only, is that passwords CAN be relatively secure. I would go with https, and make sure you dont leave any cookies (obviously). Also make sure the passwords are encrypted on the server-side ( dont just throw the plain text passwords into a sql database!!! ). For the choosing of passwords, be very strict. I am assuming you are doing on-site work for this company. I would talk to the guy in charge over there, and convince them that they NEED secure, randomly generated passwords, and that the people should not write them down. because thats not a good idea :) Overall, on the client end, dont let them choose theyre own username or password! Try to use a randomly or in-order number for the username (not theyre employee id or matching any other number), and make the password randomly generated. Also, something else to note is that maybe you should think of doing extra layers of security. For example, when they hit this https server, make it prompt them for a u/p that they can choose the password, just as a simple yet annoying step (for any intruder). Then proceed to prompt them for theyre extremely-secure l/p... Also another good idea would to IP-Lock to theyre machine (to avoid outside interferance). (I may not be understanding the situation, but you can derive off these ideas) Because, after all, if someone were to hack this at the persons desk, its just as hard to go and pull the records from a file cabinet -- both require non-digital bravery :)
Given that anyone who dons a white coat
can get any record whatsoever from
medical records to begin with, the
use of a username/password is actually a step
up in security.
As to medical data being more important than
financial, well that is simply not true with
a couple of exceptions like stigmatized diseases.
Most medical data is useless ten days out and
the Electronic Medical Record folks are too full
of themselves anyhow.
I'm still waiting for a system I can use in daily practice that is faster than pencil and paper.
A possibly overlooked, but IMO more serious question regards the actual messages stored on the system and those sent to the Doctor and the Patient. If I can get on the box, can I read the information?
What information is sent to the user/doctor when a message is stored on the system? Is a specific message id referred to in the message? Does some clue in the message (apart from the address, lol) refer, even obliquely, to the doctor/patient/hospital? (We're looking for a system id number, or message identifiction number here. Having reasonably generic information in the title helps, as well. Like, use "Notification from DocCo", and not "Info from HIV Net online!" as a title, eh! )
Are the messages on the system stored in plaintext, or indexed in such as way as to enable an intruder to determine user identity from a single table or extremely simple lookup (ID=SSN, or Last/First/MI for example)?
Are the tables/messages "for" doctors different than the messages "for" patients? Are they stored in different tables? As an intruder, could I know without guessing which table is which? Can I identify what kind or type of message is being sent by examining the table structure?
IMO, a good system would use a md5 generated key based on some combination of timestamp/username/messageid/accountno to encrypt the messages on the server, store all messages in the same table (or across several identically structured tables, randomly) If you can, obfuscate the real user information in a similar fashion. Make it tough for anyone to grok the information without tearing into your functions.
"No man is an island, but some are peninsulas."
You give patient/doctor username and 100 or so passwords, each password works only once and they must be used in correct order, when passwords run out you send them more via mail. In Finland banks use this system.
In my mind, there is *only one* proposal for information transmission that seems like it *might* actually be crack-proof (assuming the source and destination computers are secure... yeah *right*!): using quantum physics and entangled photons (the *might* is because i'm not sure we understand the physics well enough yet...). of course that would require completely rewiring the internet and coming up with a whole new definition of how a router works... if it can be done at all...
so the conclusion must be that we're voulnerable. and i think we're going to eventually have a serious global information security meltdown whether people change their passwords to 40 random digits every day or not.
In Germany every person gets a chipcard from their health insurance company (health insurance is required by law here).
These cards comply to a certain standard. Without my card, the medical personnel has no access to my records, except for special purposes where only certain partial aspects are important, e.g. billing.
I know that since my chipcard went broke after 5 years of use and my dentist could not enter the services he had made until my next visit.
I think that that is an interesting model for your problem:
One part of the system at the doctors side (reader) and one part at the patients (card).
But from my point of view this covers only a part of the problem (the german solution is several years old).
What you really need is a complete security infrastructure.
You have to ensure data integrity (against tampering), access control, authentication, digital signature, etc. From the network architects view this cries for a public key infrastructure solution (PKIX).
You might want to look at this page at securityportal.com. Its a good starting point on PKIX.
-- "Wherever you go, there you are." (Buckaroo Banzai)
It has been my understanding that, atleast in NY State, connecting a medical database to the Internet is illegal. Has anyone else heard anything like this?
Some people have a way with words, and some people, um, thingy.
If I wiretap your phone, I commit a felony. If I sniff your packets that were braodcast on the internet, etc., I commit no crime. You gave whatever information that was in that e-mail to the world, so to speak, and there is probably not even much in the way of "expectation of privacy" to protect in a civil court. About all crypto offers is that it makes people work to invade your privacy. So make them work really really hard!
My 2 cents.
I am not a security expert. I don't even play one on the internet.
But allow me to offer some suggestions on presenting your recommendations to your boss.
The biggest thing is to get him/her to consider the risks of each side of the decision. You may be able to sway that decision by piling up factoids. The other posters here have made some very good points.
Then, force her to do a risk analysis:
[Good] "Ms. Riley, two years from now, if I am wrong, I look silly. If you are wrong, the company is getting sued from all directions."
[Dangerous] "Did I mention that I have put all of my recommendations and reservations into a hardcopy archive?" Even if you don't say this, for goodness sake, do keep your own copy.
[Suicidal] "Of course you get the final decision. Which I will need in writing before I can start designing/coding. For my project files."
If you're a security wonk, then you are being paid to be paranoid. Use that. "Mr. Johnson, you're paying me to be paranoid about the security of our product".
Reference to independent authority is always good, though some bosses resent being intimidated by outside experts (whom they cannot fire). "Mr. Smith, I have consulted team members at the same security think tank used by the publishers of "Jane's Weapons Systems".
Remember, if it's not your decision, you won't get the credit for it going right. Just the blame when it goes wrong.
Thank you for asking Slashdot. I think we are all learning on this one.
Most of the posts I just read were hell-bent on making this absolutely secure. But this same lust for security makes it very difficult for the average user to logon and get the answer to the question they are looking for. A truly secure method may be crippling to the tool's purpose. At that point, why bother doing it?
What is it that you are trying to secure against? Raids by a marketer, collecting email addresses to sell his medicine to? Blackmail of a political career? Embarassment by friends and co-workers? A script-kiddie putting up a database of a few peoples' ailments? All of these things are unlikely to happen.
I say, take let the security back a notch. A good password, kept secret, is good enough. Reject the absolute worst passwords. But other than that, let the users choose their own security. ("Is this secure? Yes, if you follow these simple instructions; click here.")
This data does not have to be protected in a truly absolute sense. It just has to be protected to the point where a) the user is happy and b) the cost of getting the data outweighs the usefulness of the data.
Our company uses a similar system called "SecurID" tokens, which generate a unique number every twenty seconds or so that you use with a PIN to login to a system...
There is a problem though: Tokens. By that I mean the plurality of tokens possible, at one point I had three seperate tokens (all which look identical apart from a serial number in the back). As more places use tokens, the problems will get worse. What we really need is a standard for a token based system where you could have different services that need security transmit some kind of token generator into a token - like the SecurID token generator for the Pilot, so you could select the token account you want from one physical token.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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!
Use iButtons. And x.509 certificates.
Ummm, if you get that kind of information any other way than by phone or in person with a trained counselor I'd hate to use YOUR HMO. Geez. "Oh, by the way, you have inoperable brain cancer. Please fill out this form online and make immediate payment."
Here are guidelines for passwords:
/etc/passwd. Make sure shadowing is turned enabled. The only way to get it then is to gain root access. Then passwords are your last worry.
(1) Before assigning a password, run it through cracklib. This is an absolute minimum for a high security site. (If you don't know how to do this for a platform, hire someone who does) Cracklib will take care of all the obviously bad passwords (and some not so obvious).
(2) Lock an account out after 3 bad sign-ons. Insert a minimum delay of 1 second for each authentication attempt. This will rule out brute forcers.
(3) For UNIX, Do *not* store passwords in
(4) Force password expirations. If you have a huge number of general public users don't make this too short or you'll overwhealm your support staff with people who forgot their password.
(5) Run crack in the background.
(6) Give users easy rules to build good passwords. My favorite is the obscene-nonsense rule. Think of an obscene phrase that does't make any sense. This is guaranteed to not appear in any book and people are very unlikely to share passwords. Take the first letter of each word in the phrase and make a password out of it. There are variants for people who can't think of anything obscene.
(7) Expire out the accounts after a long period of inactivity (say 6 months or more). They probably won't remember the password anyway. When they call because they can't login your can re-vet them.
Client side certs are great for limited audiences (employees of a corp, members of a department) but would be a real pain to administer for an audience the size of the general public. Given that, my favorite is the iButton (even better if they provide USB support).
Jim Burnes
Internet Security Systems
jburnes@earthlink.net
jburnes@iss.net
Secure HTTP, to my knowledge, essentially died on the vine quite a while back. SSL won that war. Web sites prefixed with "https://" are using SSL, not Secure HTTP.
If it is, in fact, SSL, then for the type of information being exchanged here, passwords should provide acceptable security. Some important considerations are:
- The password should be entered on a form submitted via SSL. The SSL dynamic key exchange and subsequent encryption will protect the password itself.
- Use 128-bit SSL if at all possible.
- Put in fairly onerous password rules (mixed case; letters and digits; special characters; at least ? characters long; etc.)
There was a good message upstream about these same points. I mainly wanted to clarify the SSL vs. Secure HTTP question.
Personally, I would be fine emailing my doctor directly without PGP. The odds of anyone sniffing my mail packets to grab my health info seem pretty slim to me and I've discussed much more worrisome stuff in email than my medical history.
But I would NOT be OK logging into a site that was storing my info on the site with nothing but userid/password over https. The odds of someone trying to crack a web server, a machine that basically sits on the internet, are not nearly so slim. Especially if it's an NT machine - the things are enarly impossible to really lock down.
To me, https is "safe enough" for one way transmissions through a form, but not safe enough for a bunch of info sitting on a web server to be secure. I'll send my CC number to buy something from a web site, as long as the CC info is not stored on the web server itself, but on an internal server inside a firewall. I tell my employers that nothing should be on a web server on the net that they wouldn't mind having faxed to all their competitors and blown up on billboards.
Why can't you do a VPN thing with these people?
digital certificates will work.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
It's HIPAA
Check out
http://www.hipaainfo.com/
among other sources of info.
The feds are doing this one right: leave the
exact implementation to the hands of those who
know better, but state the minimum requirements.
This way instead of requiring something that goes obsolete, so long as your system does the job, you can use it.
PKI is one way to go, PGP is another...
Help achieve Liberty in your lifetime - join the Free State Project - http://www.freestateproject.org
Different realistic solutions have seemingly been covered enough so far, so I'll stretch a bit further for some food for thought. Please, forget for a moment that limits exist for implementability ;/
;)
Ultimately an individual human should be identifiable as is, without a key list printed on paper/plastic card, but not just a single password either. Also, the flesh-carried challenges should be one-use and of unlimited supply.
We do carry an extreme neural computing device on each of our shoulders, expandable to a few "animal" species (gorillas come to mind). If such an analog "computer"s likely responses to a set of questionnaire could be simulated by digital machinery, and if that set of challenge key-value (question-answer) results could be trusted upon to be static.yet of near-infinite [sic] supply, an unique challenge could be presented to a human as a simple question, to which it could answer with an appropriate key. You'd probably have to allow a few failures each time though
The keys could be logical questions about changing subjects, that touch areas of the individual's thinking known and trusted (unconscious?) to the challenger. No birth dates or such crap; rather "Does a mother have the right to shout at your little sister of age 9, if the latter behaves maliciously?". Answers could be of forms like "depends on what the shouting is for." Areas of thought where the answer is formed should be just that: based on little changing patterns related to clear concepts (family, rights, simple behavior) that can be mapped by a series of questions, yet which are individual enough to personalize us... uuh, serious oversimplifying. Well, think about it if you will. What makes one individe?
I think, therefore thoughts exist. Ego is just an impression.
I am a crypto-novice, but this is something I've always wondered about... Does it really make any difference to have username & password & secret word & (whatever) over just using a password? Isn't a name and password just really a single password that you enter in two steps? Can someone explain why name & password is mathematically different? Are two 64-bit keys different than a single 128-bit one?
Thanks!
Things you have.
Things you know.
Things you are.
Computer security, up untill quite recently, is centered around things you know - usernames, passwords, PIN's and the like. A truely secure system is going to combine at least two of the above - band machines require something you know (your pin) and something you have (your card). Getting beyone security in some buildings may require something you have (a photo id card) and something you are (your face). If the picture, you face, and the coloured stripes on the ID match, your in.
There are a number of hardware biometric solutions aviable, from finger print scanners, to face recoginition. The problem is, in this case, how you can integrate this with a http server, and for that I dont know :O
All (most) of these systems interate nicely with Novell NDS, and the Netscape http server that comes with Netware 4 (and above) integrates http security nicely with NDS (if user FOO is NDS authentacated to xxx.xxx.xxx.xxx then he is also http authentacated as well...), this is true of netscape sever running on netware anyway, I dont know if it would work quite thateasily with, say, NDS on Soloris (or Caldara) and apache. A quick search of CPAN dosent turn up any NDS modules (but you can get perl for netware) but NDS can be accesed through LDAP for which there are dozens of perl mod for (and things like php can access that nativly (apache too??)).. Actualty perl from developer.novell.com has native support for NDS access.
hehe... Of on a bit of a Novell/NDS rant there, but it may be the solution, biometric products (which you want for security) support it, and you might be able to get away with some kind of open-source solution (which Im assuming is important to you, being a ./ reader). Its quite possible that since your in a hospital, you have netware anyway, and keeping a single user tree is always a good idea.
"goofy" users who write their password on paper. Wow! I see all too much of that! I saw system admins who use telnet to login as root. I saw system admins who type their password right in front of your eyes.
These are reasons for which we have to start looking into new forms of authentication. The kind of stuff you see in movies: retinal scans, fingerprints, or to any extent, using magnetized swipe-cards with your user info. I find that encrypted magnetized cards work well, but are somewhat expensive.
We looked at PGP, and we looked at the SMIME variants. The latter, IIRC, suffers from from a recent Netscape/Microsoft implementation divergence making the one's keys incompatible with the other's (how surprising!).
Actually, this is a bit less nefarious than you think. S-MIME clients are in the process of being upgraded to allow dual key-pair implentations of certificates. It was noted that a single key-pair won't cut it for non-repudiation on systems were key recovery is in force. You therefor need to support an encrypting and a signing pair. There are incompatibilities arising in S-MIME because of this. Hopefully it will resolve itself as more people upgrade their client software.
P.S. Any misspellings or faults of grammar you think you detect are mearly transmition errors, and probably your fault a
I think in order to understand the security concerns best, it is important to consider how online banking/medical information compares with their traditional counterparts.
The trouble with online information is essentially scalibility. If informationis easy to obtain by bypassing bad security, then an attacker can get an awful lot of it. Usually, one person's medical records are not useful, unless you can get one specific person's records at will.
Since it is hard to imagine someone compromising the https system( assuming you are using 128 bit keys) the only way to "brute force" the system is to log in multiple times. This is easy to spot. The only foolproof way to bypass the security is to somehow attack the users machine.
This is easier than one would like to admit, but it scales terribly. In essence, it's no less difficult to get medical information this way than by more conventional means (social engineering, burglary, etc.)
This is not to say that this is an acceptable situation. However, if online medical information is a good idea, then there is no point in not doing it simply because the security is no better than it was in the old regime.
Thinking ahead to improve security when the time comes is a good idea. As systems and attackers become more sophisticated, this will be important, and improving security is a good idea.
You say using twofactor auth will delay things by a couple of years. Really, your answer is right there. Two years is an eternity in this business, and if you don't keep moving, you'll get run over.
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?
For example, if someone is able to decrypt a transmission between myself and my bank in the future there is a very good chance the info is almost useless. Even if I'm still using the account at the time the transmission is decrypted, I can change banks, get a new account number, etc. Medical records are different. Even if it takes someone years to decrypt (who knows, advances in hardware, cracking techniques, etc. could make it possible in a relatively short few years ahead) the info is still useful and accurate. Medical records are accurate and usefull for all time. Secure enough may not cut it for most people. Your thoughts?
Huh. You should feel lucky that you have as much security as an actual password! My investment accounts with Fidelity are protected by the combination of my SSN and a *4-digit PIN!*. That's right - all anyone has to do is get my SSN (how tough is that these days) and guess 4 digits, and they can wipe out every penny of my retirement savings (or anyone else's at Fidelity).
Does Fidelity give a damn? No way. Why not? because they have so many legal disclimers and exclusions buried in the boilerplate of their service agreement that their CEO could abscond to a desert island with everyone's money and laugh at us, and we wouldn't be able to hold them liable. They accept no responsibility for anything bad happening to you through their own mistakes, so this just isn't an issue for them.
Pisses me off!
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.
The authentication you describe seems to me to be three step but not three factor authentication...
In my understanding the number of authentication factors refers to the presence of different types of authentication. The types presently used are
1) Things you know (e.g. username/password)
2) Things you have (e.g. physical authentication tokens)
3) Things you are (e.g. biometric measurements)
By this definition what you're describing is either one or two factor authentication. I don't really understand what you mean by the challenge/response (the web page is not much more helpful), but I'm pretty sure it's not biometric... and keypairs are REALLY hard to guess, but they're still just information and fundamentally reproducable, thus not "what you have" authentication unless they're contained in a secure, tamper-proof physical token.
Clearly if a system asked a user for three different passwords the process wouldn't be called three factor auth... right?
/* The beatings will continue until morale improves. */
I'll happily sell you my complete medical records for $10 :P. You would find out I had my tonsils out and a broke my arm 3 times. I am 30 now and have only been to the doctor once since I was 12 (for a pre-marriage checkup).
Even if I had serious health problems, who cares? While I would not want the information publicly traded per se, I can think of little to no harm that can come from somebody hacking into this information. The few cases where the information might be useful to somebody also happen to be cases where I would either 1) volunteer the information or 2) they are reputable and would never hack into a system for somebodies medical records.
So, protect my bank account or my medical records...hmm, like I said, $10 going once, going twice...
(Sorry for the double-post... I hit the wrong "reply" button the first time around...)
Disclaimer: I work for Entrust Technologies, and I deal with these sorts of problems every day.
For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).
Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.
The question states that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.
Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.
Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.
I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:
- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very small 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)
- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.
- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.
Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.
Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.
Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.
"Tomorrow's forecast: a few sprinkles of genius with a chance of doom!" - Stewie Griffin
That happened to me too! I bought a used tape drive a while back. It still had a tape in it. With somebody's backup on it. We were laughing for hours. Eventually we sifted through the information, found some phone numbers, called them up, and told them what had happened.
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*)
I'm able to check the information for my 401k online. I personally wouldn't think it the end of the world if my financial information got disclosed, but I know some people would. They require 128-bit ssl to login to an account, which I initially thought really funny, because your password has to be 5 numeric digits.
/etc/password, I could probably break passwords of that form before my web browser is even finished loading, but it doesn't matter, because I'm not cracking against /etc/password. The only way I can test a password is by attempting to connect to the server. Assuming 15 seconds to test a password, since their server is fairly slow, that's 15 1/2 days for someone who knows my social security and account number to be able to get access to my account.
Now, if were cracking against
Of course, it will lock me out after like 3 attempts, so even if I had two weeks to spare, I wouldn't be able to get in. In short, password strength only matters to the degree that an attacker would be able to attack the password. If the attacker can't try passwords quickly, it is definitely preferable to give the users a password they can remember rather than something that matches the formula for "secure".
later,
kevin
Actually, I'm not too worried about my electronic bank account being cracked because it's so much more trivial to crack bank accounts physically. Just intercept the bank statement in the mail. Or write the numbers down off someone's check. Then print your own checks. It gets a little bit more complicated to cash them without getting caught... But it can and is being done.
(This is why I support finger-print signature squares on checks for both parties.)
Now, if the information concerns me (as the admin.), then I should at least check if the user is not using a stupid password.
But in most of the cases, it's up to the user. He/she should know the value of the information. (of course it wouldn't hurt to use SSL, and all that)
--
Stay tuned for some shock and awe coming right up after this messages!
Now, if the information concerns me (as the admin.), then I should at least check if the user is not using a stupid password.
But in most of the cases, it's up to the user. He/she should know the value of the information. (of course it wouldn't hurt to use SSL, and all that)
Isn't there a whole chapter about "social engeneering" (or something) on those "learn how to be a hacker in 10 minutes" manuals?
--
Stay tuned for some shock and awe coming right up after this messages!
Be PARANOID!!!
Don't forget that in the highly unlikely event that someone would go to extraordinary lengths to get someone's medical records, they could probably break into the hospital's file room and find the actual chart MUCH easier than they could break 128-bit encryption. On the other hand (speaking as a physician), it often seems like our medical records file clerks take many times longer than the existance of the universe to locate a particular chart ;-)
A DOS attack is an attack on the HMO / Ins. company / whatever company's profit.
I respectfully submit that most corporations would consider an attack on their profitability MUCH more serious than an attack on my privacy!
My bank uses one-time pads as a method of authentication. It really is easy. I have a paper with 50 passwords, they're used as passwords in the order listed in the paper, and each password expires after use. Once I have used my passwords, the bank sends me a new set of passwords (through "real" mail). If implemented properly, this combined with SSL should be really secure.
Will work. PGP is old. D/
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!
Passwords are security through obscurity. Authentication should rely on publicly known and knowable things like biometrics, not on "secrets" like keys and passwords. And of course, the software and firmware source, schematics, PAL equations, FPGA specs, etc. must be engraved on a brass plate next to the biometric device, in all cases. Because it MUST be open source!!!
Everybody knows security through obscurity is bad, bad, bad.
Now run around like good hackers chanting "Security through obscurity baaaad!", "Open sores good!", "buck-buck-buckaw!", etc.
Security and the concept of a secure system is something that is used to let the users sleep at night. People would prefer to think about their personal information being well protected, and often it is simply impossible to keep the data secure and still make it useful. This is the primary problem with "security," in my opinion. How do you keep the system secure, but keep it useful?
In this case, our problem is that we are using username/password authentication to send and retrieve the most sensitive of information. The security of this information could literally make the difference between life and death. However, if you keep the data secure enough that it cannot be compromised, it is no longer useful to your patients.
So we now find ourselves wondering what method of authentication should be used, and how the data should be transmitted. I am of the opinion that public/private key exchanges should take place, and the authentication should take place in this manner. However, I do not believe any current web browsers support the ability for you to generate an https certificate that you use exclusively. If you could generate a public/private keypair that was used for every session, you could use simple challenge-response authentication. SSH uses this scheme with RSA authentication.
Of course, this assumes that the users private key is secure and its private key must be, to a certain degree, secure as well. The last thing you want is patient information disclosed to the masses.
I'm rambling, I know, but these are just my thoughts.
--
If there is a God, you are an authorized representative. - Kurt Vonnegut Jr.
Forcing users to change their passwords is nice, but for a medical site, people will only use it when there's a problem. For non-chronic cases, it may be months or even a year before the user goes to access the site again. How can password changing and infrequent use be reconciled?
main(O){10<putchar((O--,102-((O&4)*16| (31&60>>5*(O&3)))))&&main(2+ O);}
LN2 is cool!
My bank offers internet banking. Access is through the customer number and ATM password.
Consider for a minute that the customer number is on all of the correspondence I receive from them, clearly visible through the window envelope. It is also on the debit card used at the ATM.
The ATM password is four digits, numbers only. No changes to alphanumberic are allowed. No longer passwords are permitted.
How difficult would it be to access my account or any other of the bank's customer accounts at their web site? How long would it take to try the most common number combinations two a night until one clicks? (try 1111, 1234, 9876, the last four digits of the customer's telephone number, etc.)
Of course, accessing the account only lets them view the customer's information and move money between the customer accounts. UNLESS -- the customer signs up for bill payment. Then money can be sent anywhere, even outside the banking system. Conveniently, one can sign up for bill payment at the web site, with no other security checks! (Once you guess the password and are in, sign the victim up for bill payment. It could make transferring the money to whomever you want so much easier!)
When will banks take authentication seriously? They DON'T (1) force strong passwords, and (2) force password changes, or (3) allow strong passwords. Don't even think about biometrics or PKI. They DO (1) force weak ATM passwords onto the Internet, (2) use a readily known username (the customer account number).
Anyone care to guess how long it will be before a bank customer gets cleaned out?
The value of password authentication depends on two things (provided shortcuts are not provided): (1) The number of possible passwords that can be selected (2) The amount of time required to try each password. (By no shortcuts I mean that a potential attacker is forced into a "brute-force" attack at some level.) Let me explain. Suppose you have an average joe who selects his password as one of "nothing", "password", the name of his dog, the name of his wife, the name of his car, etc. How many possibilities are there even if a password is chosen poorly? If you can assume 200, which is admittedly nothing in comparison with crypographic attacks, you still have a useful mechanism if you enforce account lockout. Assume that the account locks after three unsuccessful attempts or more than an average one unsuccessful attempt per day. If your educated attacker has to go through an average of 100 possiblities at 2 possibilities per day, he is expected to take well more than a month to crack a particular account. Meanwhile, your audit system should be going off every day, giving you plenty of warning in the expected case. If you correlate your alarms by network node as well as accounts attempted. If you pay attention to your logs, you will probably know about attacks in plenty of time to deal with them. If you can get your users to choose even random dictionary words (say 60 000 possibilities) you will have more security than typical four digit bank PIN numbers. If you allow attackers to learn anything other than a pass/fail per attempt, you will give away the farm. If you don't limit the rate they can try, you may need passwords worth 64-256 bits. If you audit carefully and ensure that attackers can only get a very few attempts without being noticed/locked out, your chances of a breakin will be one in the typical number of passwords from which users select. On the other hand, if you try to add other factors, they can be stolen, too. All cryptographic processes depend on generating random numbers secretly. You can authenticate very securely with you favourite smart card, biometric, or other do-hickey, but if you insert an open network between the prover and the verifier, you have given away the farm. Passwords can be changed very economically. Summary: Use a username/password system, get users to choose passable passwords (just not everybody choose "password"), and audit real carefully. You will get your notice about any attacks in plenty of time.
If I was faced with this problem . I would simply enforce strong passwords on the host. I would say at minimum three character sets of the four available upper case alpha, lower case alpha, numeric, and punctuation. I would not preassign passwords. I would enable password lockout for more than 5 failures. I would log multiple failures perhaps even send a page or email on 5 failures. I would require passwords be changed every three months. And would not allow repeating the previous 5 passwords. With these steps taken your password scheme would probably not be your weak link. The thing I would worry about at that point would be the security of the bastion host. In other words which bug in which daemon or protocol is going to allow someone to root the box. Faced with the afformentioned password scheme the cracker will look for an easier way in. It's kinda like if faced with a reputable proxy firewall a cracker wont attack the firewall. They will simply use a war dialer to get into your network via dialup. Any way thats just my opinion.
warning, this is a plug!
I am a developer for V-ONE corporation
(http://www.v-one.com). We develop secure internet proxy products which support web based key deployment, a variety of two factor authentication mechanisms, and when used within the United States, 3DES shared secret encryption. Our SmartGate product can provide public key based key deployment, mutual authentication, and the best data security in the industry, without ever having to deal with physical tokens (and using a freely available client). In short, we solve this problem. Without the weak security of SSL, and with the easiest authentication and key deployment process available. Check out our demo on our web page.
...and yes, both the client and the server run on Linux.
--
What happens when you outlaw guns
Nix the username/password, and go for a digital certificate. Stick it on a smartcard, and you've got yourself an EXTREMELY secure solution, that is cost efective, and easy to implement.
There are 2 main issues;
1. Password compromise on the originaotrs machine, and
2. content control in the central server.
PGP does nothing for (1) - password interception is still equally vulnerable.
The need to carry around PGP certs totally removes portability. Doctors and nurses do not use the same workstation for more than minutes at a time.
Server storage of PGP keys means a password must be sent across the network to access the keyring, which is no better than what they have now.
Content control is not helped by PGP - but legitimate distribution in the medical facility is severely restricted. Password and pass phrase merely makes for a effectively longer password length. Still vulnerable to sniffers, as are on-screen keypads.
Lyal
There are 2 main issues;
1. Password compromise on the originaotrs machine, and
2. content control in the central server.
PGP does nothing for (1) - password interception is still equally vulnerable.
The need to carry around PGP certs totally removes portability. Doctors and nurses do not use the same workstation for more than minutes at a time.
Server storage of PGP keys means a password must be sent across the network to access the keyring, which is no better than what they have now.
Content control is not helped by PGP - but legitimate distribution in the medical facility is severely restricted.
Password and pass phrase merely makes for a effectively longer password length. Still vulnerable to sniffers, as are on-screen keypads.
Lyal
I agree - passwords are the only efective tools right now.
All certificate schemes need a password to unlock them - so they offer NO BETTER authentication than a password, at massive cost - passwords come free on many operating systems
Biometrics may have a future, but not yet.
Smarctard would not be hard to add in - 6-9 months, max. readers are $10-$25 - minimal difference.
lyal
If a password gives you access to a computer account, it makes sense not to write it down. But if it only gives access to your medical records, you may as well keep it with your medical records, or in your home. If someone is willing to break into my home to find out my medical history, I wouldn't consider that a serious security hole. After all, while they are in my home they can do numerous other things to violate my privacy.
I think a little perspective is in order here. Anyone who is physically snooping on you has already violated your privacy, and access to computer records is only a small part of the damage they can do. When it comes to computer security in situations like this, what is important is that bad guys aren't able to use just computers (and no actual snooping around) to find out people's medical records, and the suggestions I've seen here seem to indicate that a well designed password system can prevent such attacks.
We had 2 passwords. Customers loved that, because :) :)
they could keep `critical' accounts with our bank. Per legislation, Chief Beancounter carries criminal
responsibility tohether with Big Boss if something goes wrong, so they just
made it so one person knew only one password
In fact, one password was to encrypt the request with PGP,
another had been passed together with client ID to our webserver, which spawned a process
that identified itself to our banking system with client ID and the second password.
Also, I guess sane client IP checks. This can be easy with corporate financials but I'm unsure about patients.
Corporates normally have only one machine with fixed IP from which transactions can be performed. If your patient also has a fixed IP, you can include
this as an option. Of course, IP datagrams can be faked, but this is another story. In fact, who is going to contact his doctor from a public machine? Well, there are some subtle details that just don't fit into Lynx editor, so feel free to email
KuroiNeko
Once financial records are stored in insecure ways it will become fun to crack them . Trust me . Or more to the point ... Don't trust me . Your Suqire squireson
I often recommend to people that they write down
their password - depending on what the risks are. I am not worried about someone breaking into my house to get my password for my medical information; it would just as easy to break into the doctors office to get much more complete information.
Writing your pin number on your credit card is a bad idea.
Writing your password down is a good idea if the reduced security it gives you is balanced by having a better password that is changed more frequently.
2. As many of us know, 99.9% of the population can't make their own decisions, especially when it comes to anything-computer-related. Therefore, from that point of view, the current system is possibly not secure enough. There are plenty of ways of making a system secure which don't rely ONLY on username/passwd authentication. My own leaning on this is that because people are generally ill-informed (ie: generally don't take the time to learn) about computers and the related stuff, perhaps a deeper level of authentication would be A Good Thing (tm).
Intel Inside: The world's most commonly-used warning label.
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.
The keys-on-floppies is almost a nice idea. What I'd like to see is a durable, relatively inexpensive smart hardware device that interfaced the computer via a floppy drive. You'd have a keypad and display about the size of a floppy, with a flexible ribbon attaching it to the computer interface. The computer would send a request to the device by "writing a file" and would pick up the response by "reading a file". For the poor iMac users, you might have an optional USB interface. [I like the idea of a USB-connected smart device, except 1) you'd want some sort of retractable cable to allow the keypad/display to be positioned away from the USB port, and 2) success of the iMac notwithstanding, 3.5 inch floppies are much more prevalent and better supported than USB.]
I just imagine lots of docs copying their floppies and challenge-response sheets so they won't have to lug them around. With a smart hardware device, that would not be an option, and you'd address the problem of compromised client machines.
-Peter
Then it's easy to disable someone's account by just writing a program to make bogus password attempts.
IMO, more complicated security measures than UN/PW aren't necessary IF and ONLY IF A) you're going to be using SSL connections (makes it difficult to snoop) and B) you strengthen the UN/PW authentication scheme somewhat. (I.e., people's usernames are difficult to guess, and people choose/are forced to choose good passwords. The aim of this being to make brute force and lucky guessing difficult).
These two things taken together will probably ensure adequate security for this particular application. While I would hesitate to put any permanant medical records under this level of protection, for the relatively transient messages between doctor and patient I think this much security would be adequate.
Now, of those two things mentioned above, the second one, item B, is going to be the hardest to deal with. So I have a couple of suggestions on how one might make it work better...
First, in the spirit of making both the passwords AND the usernames difficult to guess, I suggest you "decouple" the username from the user's actual name. (For instance, my credit card number is uniquely mine, but it has no relation to my name.) I suggest that each patient is assigned a large random number for their "username." Call this an "account number" if it makes you feel better.
This number needs to be unique to each patient, but it also needs to be mostly, if not totally, random and also unrelated to their name. (This makes it so it can't be guessed easily.) Resist the temptation to just assign numbers to patients sequentially! That makes it really easy for a malicious individual to guess valid numbers.
Making this number have 15 or 20 digits (say, a thousand quadrillion or so) and randomly assigned will make blind guessing extremely unproductive, and will also make brute-force crack attempts very time-consuming for the cracker and very conspicious in the site's logs.
Now, how about making sure the passwords are difficult to guess? To solve this problem, I suggest using a pass*phrase* rather than just a single password. (I honestly think that 8 character or less passwords were NEVER secure enough. Not because of the encryption algorithm or anything, but simply because it's too easy to look over someone's shoulder and observe a large portion of the password. A passphrase does not eliminate this problem, but it does mitigate it a fair bit.) This passphrase will be chosen by the patient, and only they know it. It should be checked to make sure it's not a simple repetition of their name or such, and it should be checked against a common dictionary of phrases. But other than that, it could be anything. Leave it up to the patient to decide. If you want to be REALLY nice, make it case-insensitive. (Though good luck getting that idea to fly with your boss...)
To sum it up: First, the patient must make an SSL encrypted connection. Next, they need to input a fairly long (20 digits?) "username"/"account number". Then they must input a non-obvious passphrase. Only then are they granted access to the messages from their doctor.
This scheme is probably slightly more secure than standard UNIX username/pw protection, mostly because of the difficulty of guessing or brute-forcing the "username" and passphrase.
But is it workable? Well, probably. The fly in the ointment is that while this scheme is ostensibly "something you are" (username) combined with "something you know" (passphrase) in truth it's actually just two seperate "things you know." And therefore, people will be tempted to write down their username and possibly passphrase.
But honestly, I think that's unavoidable anyway. People will always write down their usernames and passphrases for infrequently used information like this. So long as they are warned in advance that if they do choose to write it down, they must keep that written record in a relatively secure place (like a filing cabinet in their home - but NOT like in their wallet) it's probably okay.
The main problem here, in my mind, is not people writing down their identification credentials. So long as those are safely stored, that's probably not a big deal. (And if they're not safely stored, well, can you really be held accountable for the actions of a person who doesn't do what they were explicitly told to?)
The real problem is brute-forcing and guessing of easy usernames and easy passwords. The design I've outlined in this post minimizes those attacks, albeit at the cost of slightly loosened security in the form of people writing their access credentials down. In this case, I believe that tradeoff is worth it.
Of course the ideal situation would be that everyone has an retina/iris scanner on their desktop. If that were true (and in the future, who knows?) then an encrypted connection like SSL and an retina/iris scanner would be more than sufficient to prevent all casual attempts to break the system, and probably most serious and skilled ones. But since "something you are" authentication, like iris/retina scanning, doesn't seem feasable yet, a relatively strong version of "something you know" would seem to be the next best thing.
-Ben
Did you mean 'hacker' or 'cracker'?
Do you know the diffrence? I don't think you do.
POP3 has an option to verify passwords by comparing hashes--the password is hashed on the client's side, with the hash-method being based on the date/time/etc, and hashed on the server's side. Assuming that you can't reverse the hash, it seems like a fairly secure method, save the fact that brute-force cracking is... um... trivial....
That seems like the biggest problem with passwords (well, the common `bad passwords'--in the event that the password-handling and I/O systems can hdle all 8-bit characters, an 8-character password is 64-bit, and a 16-character password is 128-bit...).
Well..., it's just the transmission-method that's notable, there, if passwords can be brute-forced.
Hrm.
As far as not being to get everyone to install key-generation software, you -could- write a key-generator up in JavaScript. It'd have to be transmitted across the network, though..., initially.... Ack.
-rozzin.
Their site is at: http://www.arcot.com It uses a PIN to protect downloadable keys on the client side. They way it works is like having thousands of keys under your doormat out of which only one key is the correct key but you have to try the key to find out if it is the right key. Use of SSL is required. Only real downside is that WebFort requires client-side software. Good luck. Don Park FYI - I used to be a consultant to Arcot.
I think the fundumental problem is not that the usr pass auth can be broken bucouse it is not the weakest link in the systome. The weakest link is the clients own computer. If I were trying to break the systome I would brake the computer that thay log in form. It will most likley be a windows box that thay are the sole admins of. Most people can't even be botherd to rember good passwords letalown keep there computer secure. becouse of this I beleave that the only reasonable safe thing to do is so use a off net chalange responce systome. by off net I mean one where the divice (pilot, caculater, pad of paper) is never connected to the net. this way there is little chance of an atomated attack agenst it. For your solution a regular username and a password combined with a list of one time passwords that you postal mail to the customers would probaly work very well at protecting 99% persent of you clients. The one time passwords will protect them from all but the most advanst online attacks and the password that thay are soposted to keep in there head will protect them from people snooping around there desk.
Any mechanism that disables an account after a number of unsuccessful tries is vulnerable to denial-of-service. An attacker who would like to prevent legitimate users from accessing the system will simply try a random password every one hundred seconds for each account once per day (presumably from one or more compromised machines to cover tracks). The system will be quite secure because no one will be able to use it.
In general, it is unwise to assume that you can secure a system simply by asking yourself where the holes are and plugging them. Anything you forget is a potential problem. A better approach for production systems is to apply caution systematically. For example, dispense with features and services that are not essential. The goal is simplicity because a complex system cannot be secure.
Do patients need to access medial records from the web? Do they need this more than they need privacy? Only if the answers are yes should such a system be installed. If some patients are willing to take this risk then expose only the corresponding accounts. An account that is accessable from the internet protected only by a password is a liability that should not be forced on the meek and uninformed.
does any one know of any biometric authentication devices which are compatible with Linux and/or MacOS?
Fingerprint would probabally be the best option for us because of cost. Something like the biomouse which has fingerprint and smartcard would be even nicer.
Certs are expensive. So is getting an accredited CA, not something that fell of the back of a truck.
Don't forget the bandwidth and storage overheads
Bandwidth the spin the certs around
Storage to archive the signed transactions - or don't you want to prove what happend, when?
Lyal
Accually it isn't but the days of passwords being effective are over.
A cracker can guess a password by using old tecniques detailed in security books published in the 1980s. Such tecniques like "hack/hack" weren't very dangerous at the time but did provide a useful understanding of how a cracker could break in.
Today a cracker could effectively use hack/hack or other published tecnqiues.
Hack/Hack BTW is a tecnique publised in "Outside the Inner Circle" In short it's "enter everything" not very effective over a 300 baud modem with a SysAdm reading the logs of 100 to 500 users logging in a day with only 10 to 50 mistakes to look over. Today with 56k and up and logs so long a SysAdm could sleep reading through the mistakes log and miss over 1,000 bad passwords from one source.
Also more and more "real world" users use easy passwords in some cases they are even recomended that they use easy passwords (easy to rember = easy to guess).
Also a cracker could grep passwords over Internet trafic if the password itself isn't encripted. In the past a landline connection was secure enough to not worry about crackers.
Finnaly many less tech savy types in the paperwork side of the job aren't going to think about the implications of giving someone a password over the phone.
"Uhh gee like didn't you just GIVE WAY the ONLY means of verifying the user?" "No I just gave em there password"
Passwords are good but only as a part of a whole security system.
I don't actually exist.
Obviously the calculator contains a shared secret, so you would want it to be tamperresistant.
Also the calculator could be stolen and the owner might not be quick enough in discovering this and reporting it -- a username/password combo are used to counter that. Of course the odds of your key getting stolen are not that big, so security of the password itself is a lesser matter.
Also you'd want user/password on the users application and store data encrypted on the harddrive (ABN-AMRO and SNS do NOT do this, sigh), but if you don't want to ship an app, you can leave client-side security to the users themselves. After all if people are abusing the computer in their own home, they have a far wider problem to think about than just their medical data...
Encrypted filesystems should really be included with operating systems, anyway..
Ow, and of course, all comms should be encrypted. Validity of a certificate is quite easily established by shipping a fingerprint with the calculator via registered mail (or have clients pick those up in person), which should saveguard against man in the middle attacks..
The nice thing about calculator-type tokens is that you don't need a smart-card or swipe-card interface on your computer, plus it works stand-alone, and can be made tamperresitant (of, if you're to belief cryptocard.com 'tamperproof').
--
SCO employee? Check out the bounty
Ding! Wow! Where did you get that assumption? It would not be any lack to technical options that would hold you up. I know that RSA Security -- the guys who make the ACE authentication server and SecurID (two factor) tokens -- sells an ACE/Agent which can be embedded in a MS or Netscape server to provide what RSA calls "WebID" authentication, which could painlessly (although not without cost;-) layer two-factor authentication on top of your architecture.
(I presume other vendors of OTP tokens offer comparable systems, but I work mostly with ACE/SecurID and don't know the innards of the WebID alternatives. With the deal between Red Hat and RSA last week, WebID for Apache could be on the horizon. RHSS already ships with CryptoCard token support, doesn't it?)
WebID filters incoming HTTP or HTTPS calls to a object, page, volume, or a whole website -- and requires the incoming user to present both a SecurID 60-second tokencode and a user-memorized PIN to access a protected page or resource. (It can also allow plain HTTP calls to some pages, and require a HTTPS connection before it will allow even a properly authenticated user to access others.)
To establish a pseudo-session and maintain "state" (logically linking the many discrete calls that make up a typical WWW connection) WebID drops an ephemeral cookie onto the user's browser. The cookie can be set to time out after a period chosen by the webmaster, and it is always voided when the user closes the browser application.
WebID with HTTPS is used as the basis for online services in some banks, notably to secure commercial banking services for corporate CFOs and the like. With regard to other high-value links in other industries, note that most commercial VPNs (like virtually all commercial firewalls) now ship "SecurID Ready," with an embedded ACE/Agent, due to market demand. Even SSH was adapted for token support early on. I generally favor end-to-end crypto myself, but strong user authentication is the natural complement to link crypto for high-value data. (The market sez so!)
So tell the Boss that what your site is proposing offers, by contrast, an unusually low standard of security and confidentiality for sensitive or valuable data. That might, at least, focus his attention on your other arguments.
With regard to your specific situation, I'd say your instincts are right: the assets you are protecting do require the additional security assurance of two-factor (something known, something held) user authentication.
The architecture you describes intrigues me (and gives me hope for your Cause;-) This whole design seems to presume that the private medical information your system routinely handles can not be safely deposited in the user's desktop PC -- even if it could be safely encrypted for transit. (A browser allows the patient to read, but by default -- which guides most of us, neophytes most of all -- does not save it to disk on the patent's desktop.)
That seems to be a very sophisticated view: sensitive to the frailties of Wintel PCs, and aware that housemates of the patient (perhaps even some who share the same PC) may be a major threat to patient's privacy in this special context. I'm surprised that an institution so savvy the threat context around medical data and the patient's home PC would not appreciate the additional strength implicit in two-factor authentication.
If, as I presume, your Medical Masters do appreciate that the data you are protecting is valuable, it seems to me you've got two arguments to develop: the relative strength of two-factor authentication, and the relative weakness of static reusable passwords.
Two factor passwords are stronger because they require two separate modes of attack by anyone who seeks to compromise the authentication system. Any attempt to compromise the tokencode requires illicit access to the physical token; any attempt to compromise the user-memorized PIN requires eavesdropping or shoulder-surfing. The use of a token -- something physical and personalized (typically carried by the patient/doctor/user, perhaps as a key fob) -- hardens your system at both ends, since stealing it requires a physical attack. Cyberbandits don't cut it. With SecurID, no tokencode is valid for more than 60 seconds. WebID extends that briefly with its cookie, but misuse would require hijacking the user's PC while the patient was connected to your website. (A potential threat still, but remote and unlikely in this context.)
The weaknesses of passwords is a big topic, but in this special situation -- where the patient is probably not cyber-savvy, probably rarely uses this access method, and is probably accessing the website from home -- I think any thoughtful analysis would predict that most users will write their password down and store it among their personal papers. (Given the caution that went into your architecture, I'd be surprised if that didn't jibe with the expectations of whomever designed your whole system.) That reduces the security of this whole web-based scheme to how well the patient hides or otherwise secures a piece of paper.
I suspect the person or team who designed this architecture (even those who studied it before approving the expendature for it) would not be satisfied with that. You may have allies all around you. Good luck. Don't doubt yourself -- you are right, even if you don't win this one;-)