Username/Password - Is It Still Secure? 305
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 not PGP? (Score:2)
User/pass (Score:2)
What I wonder is how adding a second authentication scheme could delay the project for so long.
How can you call something "secure"? (Score:2)
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
Just more things to forget (Score:1)
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
At least you know what you get... (Score:2)
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...
It makes me nervous (Score:2)
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
Two Factor security should almost be mandatory (Score:1)
"Good" passwords (Score:1)
I hope this was helpful, I'm not just making up an excuse when I say I'm hungover.
-nme!
Alpha-numeric (Score:1)
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.
Passwords (Score:1)
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.
--
Security Minded. (Score:1)
"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
My bank (Score:2)
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
Paranoia (Score:1)
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
Passwords -- Yes and No (Score:3)
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 [ibutton.com].
Crypto iButton? (Score:1)
www.ibutton.com
Re:Why not PGP? (Score:1)
SHIT SORRY...wrong news item! (Score:1)
interesting trend... (Score:1)
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?
---
Re:User/pass (Score:3)
Not true. I implemented a (prototype) secure web email system which simply locked the account for 10 minutes if you got the password wrong 3 times. You could brute force it, but it would take a real long time!
I think that username/password is perfectly secure from a _technical_ point of view - the problem is people write down/share/give away their passwords. Of course this is up to the user in question, when it's their medical data at risk they may be more careful!!
And of course the following rules should _always_ be used:
* Change passwords at regular intervals
* Proactive account lock outs
* SSL encoded password transmission
* Crypto secure passwords (e.g. non-dictionary words, punctuation, numbers etc)
* Minimum password length
As an aside...I can see why banks are targets (I work for an major bank and our dialin systems are secured with one-time key systems) but why would someone want to pretend to be me when talking to my doctor?? What would motivate the cracker in question to spend however long it takes to bruteforce/man-in-the-middle this website?
Username double password? (Score:1)
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.
Fine, just expire the password after bad tries. (Score:3)
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.
What's the point? (Score:1)
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.
HIPPA Regulations - go with PKI (Score:2)
Hope this helps...
Fincancial vs. medical privacy (Score:4)
I'd be much more worried about medical records. (At least in general principal; there is, at the moment, nothing too terribly embarassing in them.)
Doesn't the HTTP 1.1 spec allow for some sort of challenge-response authentication? I think that would be significantly more secure than a simple password scheme. Mandating some sort of smartcard on the doctor's side would also be a good idea, but might be difficult to implement.
Re:Why not PGP? (Score:3)
Offline vs. Online attacks (Score:2)
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 [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
Regarding Password Security (Score:1)
Two Issues (Score:1)
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.
Hushmail (Score:1)
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
Use SSL Client Authentication through certificates (Score:2)
Passwords *can* be enough... (Score:3)
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.
Simple Concept (Score:2)
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)
Re:Fine, just expire the password after bad tries. (Score:1)
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.
Be careful. If you send the password near the beginning of the transmission without much random session salt then the attacker will be able to execute an offline brute-force search. Locking out after a certain number of bad passwords only prevents online attacks.
Sumner
Security (Score:1)
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
Secure and easy (Score:1)
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
paranoia, i don't think so (Score:1)
Re:"Good" passwords (Score:3)
There are a lot of stupid people out there, and once you start enforcing password quality rules, they'll get confused. Faced with something like the RedHat password quality checker, which requires a non-dictionary-word, and doesn't allow stuff like "t3th3r" or "gr0up13s" either, many people will either give up, or write the password down.
The more complex the restrictions, the harder the passwords become to remember, and the more likely they are to write them down.
One nice idea would be to make users accept some form of licence, which makes it clear that if *they* compromise their password's secrecy, you're not liable.
For more security, I guess you'd need some form of swipe-card or something (or the calculator thang described elsewhere), which would obviously up the cost of the project.
--
CryptoCards (Score:1)
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.
Re:"Good" passwords (Score:2)
Of course, you could give customers optional levels of security: "You may stick to a login/password, or you may pay $20 for a card reader for your PC"
--
Something you have + something you know (Score:1)
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.
Single factor auth is not enough (Score:5)
I'm the sysadmin for the PCASSO Project [ucsd.edu], 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 [samag.com] about some of the things we dealt with), but is far more secure.
--
-Esme
Secure authentication (Score:5)
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.
Perhaps a bit paranoid... (Score:2)
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.
---
It's not that username/password isn't secure. (Score:1)
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.
Safe? Yes, with considerations (Score:3)
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."
Re:Why not PGP? (Score:1)
Suggestions (Score:5)
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.
Re:Why not PGP? (Score:1)
Re:Fine, just expire the password after bad tries. (Score:1)
Uhm, but then this may lead to DOS attacks, although this could be far less interesting for malicious people.
Re:Passwords -- Yes and No (Score:1)
Security beyond the computer (Score:2)
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.
Re:How can you call something "secure"? (Score:1)
---
Medical Health Issues (Score:5)
My bank doesn't use just username/password (Score:2)
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*
But then again it is only messages... (Score:1)
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
Re:Why not PGP? (Score:2)
Who are you securing the system from? (Score:1)
It seems to me that where you concentrate the most effort on your defenses depends on which threat you consider most significant.
Re:CryptoCards (Score:2)
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
Just choose a good password (Score:1)
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
Re:"Good" passwords (Score:1)
And now think about having even more effort on the customers side... they simply won`t accept it and use another service. We're not talking about an application for your average ./er but the average internet user (AOL?:)); PGP was mentioned, which isn't that easy to use either (i know there are Frontends, but still...). So if nobody comes up with a cheap, secure *and* easy to use way of authentication, l/p will be here to stay.
Patient data: clear text is insecure (Score:1)
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.
Username/password is weakened by overuse (Score:1)
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.
HTTP/1.1 authentication (Score:1)
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.
Is complete security really needed here? (Score:1)
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.
-----
Snail mail on mistakes (Score:1)
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.
This scares the heck out of me! (Score:1)
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.
Patients not clients (Score:2)
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
Re:User/pass (Score:2)
Those are all good ideas. Personally, I like to allocate longer pass phrases. Punctuation is allways to be encouraged.
An important factor to consider with requireing passwords to change, providing random passwords, etc: If it isn't easy to remember, the user will write it down no matter how many times you say not to. Phrases are generally easier to remember than a single non-dictionary password.
Everything is hackable... and always will be... (Score:1)
Is token based authentication even an option (Score:1)
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...
Don't let them pick a password (Score:2)
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.
---
Two Factor Authentication is much more secure (Score:1)
- 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 [rsasecurity.com], 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
Re:Passwords *can* be enough... (Score:2)
I think that, pragmatically, single password authentication is all you can expect users to adop and managers to approve. So we agree.
However, I would disagree that we should keep people away from their folly by not advocating and more secure authentication schemes. After all, if a more secure authentication scheme is not available, who, in fact, is the fool - the fool that has to use the scheme, or the fool that designed and implemented it in the first place?
--
online banking in switzerland (Score:1)
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
SRP is *essential* for networked passwords. (Score:2)
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 [counterpane.com].
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!
--
Re:Paranoia (Score:2)
One of the basic tenants of the patient/doctor relationship is confidentiality. A nurse where I work recently was posting on an online medical board and gave just enough information about a case that the patient might be identifiable. She was fired.
What happens if your employer finds out that you have a possibly terminal illness? Does this affect your promotion schedule? Do you want your neighbors to knows that you have an STD? Are you less likely to go see a doctor about awkward problems if it's possible the information might become public?
We have extensive security measures to protect information from doctors and nurses who don't require immediate access to patient data. We have an entire security subsection for employees and vip's who are admitted, so that even IS folks can't see their co-workers data.
To sum up, patient data requires more security in our environment than anything else, including payroll, billing and corporate strategy. I would probably recommend a SecureID type solution for a case like his.
Re:Why not PGP? (Score:2)
Why not RSA + iButton? (Score:2)
Ask what official policy is on cracked accounts. (Score:2)
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.
Use SSL's Client Auth (Score:2)
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
Re:Suggestions (Score:2)
As for the cat, well, you could argue that it's probably not authorised to look at the data. :) Seriously, though, a sufficiently clever program should not only take that into account, but even be able to use that for secondary authentication. (Your cat will have a unique "typing" style, too, so by training the biometrics database to recognise your cat, the computer would have further confirmation of your identity, whenever your cat decided the keyboard was a great place to stroll.)
Re:Fine, just expire the password after bad tries. (Score:2)
That's very insecure.
It stops brute force cracks OK, but it does nothing to stop shoulder surfing and written down passwords. The user community here will contain significant numbers of non computer-literates; they will write the passwords down.
A major security consideration for this system is security of children against parents, and vice versa. Religiously up-tight mother searches daughter's bedroom to find the password on a Post-It and then discovers the birth control prescription ? That's a scenario that's almost guaranteed to turn up sooner or later.
Re:Suggestions (Score:2)
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.)
Goddamn it. Now I have to go and change all my passwords. And I figured I was totally secure in using that info too.
Re:HIPPA Regulations - go with PKI (Score:2)
job didn't work out (I decided to relocate to hot and sunny Las Vegas) I still remember a few tidbits about the process:
1.) Highmark was going to be making medical records online and available to healthcare providers. The highmark folks also said their were federal regs requiring a PKI solution.
2.) Highmark was looking at implementing an Entrust or similar solution where they would be there own certificate authority. My thoughts were that this was unneccessary and they could have implemented the solution much faster by using an already-existing certificate authority (I really only looked at Verisign, but there are now tons of others) PKI costs $$$ but an ounce of security now is worth a pound of legal settlements for improper disclosure later.
3.) PKI solves a lot of user authentication problems. Being able to revoke certificates means you can survive compromised certificates. It's also great for authenticating users, since the certificate can be used for digital signatures. That helps higmark since they are an insurance company and they want an audit trail to prove that payments were agreed to or paid for. Once you've digitally signed something you also can't say it never happened.
PKI Is expensive. It's cutting-edge. It's hard to implement. But from what I saw it looked like the way to go.
Of course, any system is only as secure as people make it. Highmark was talking about using solaris and an oracle backend database. Coupled with enough diligent adminstration it seemed like a good start. The problem with insurance records, medical records, and large sums of cash being electronically transferred is that good isn't enough.
The liability issues of releasing patient medical records are pretty severe. I'm surprised to hear that the original poster is the only one raising concerns. If it were my company I'd fire the entire implementation team for even considering a basic user/password authentication scheme. It doesn't scale well, and is vulnerable to all manner of attacks.
When it comes to the most confidential information about YOU it makes sense to err on the side of paranoia. Do you really want some script kiddie browsing through your medical records to see those blood test results for HIV antibodies or that trip to the psychologist 15 years ago? If ever there was something thatneeded a long, careful and well planned out security infrastructure surely it is this.
--chuck
Writing down passwords (Score:3)
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
Re:Secure authentication (Score:2)
I still think you need an external key source such as an ibutton or a securid card...
Re:Passwords -- Yes and No (Score:2)
How secure is it? (Score:2)
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?
Let's Be Realistic (Score:2)
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.
medical records on-line and accessible? (Score:2)
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.
Give them options (Score:2)
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.
your finance records/transactions open to all (Score:2)
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
Re:Fine, just expire the password after bad tries. (Score:2)
Know why I'm not concerned? Because nobody cares enough to bother doing it. Sure, you can deny me access to my account with some research to discover my provider and id. But why would you? You could attack it, break my password and move my money around...but why?
The information, while important to me, really has no value to anybody else. It doesn't need to be perfectly secure. It just needs to be significantly more difficult to compromise than it's worth.
Security costs money and makes things difficult, whether it's in the computer world or the real world. If I really want to secure my CD player, I'd put it in a safe. Instead, I just put it out of sight in my desk drawer because it's not valuable enough to be so paranoid. The same criteria of evaluation and appropriateness apply to information.
The man didn't ask how to make a completely uncrackable network system. It's not possible. You could poke holes in anything anybody could offer. He asked what a reasonable level of security would be, given the type of information and the costs associated with implementation.
Token based is better than host based (Score:2)
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!
Please give references. (Score:2)
Also, the key stretching paper explains why the technique described there is more appropriate than the technique you reference for passwords.
--
Re:Secure authentication (Score:2)
People have to be trained in security.
If this is a concern (you can't fire people for writing down passwords) then let them last much longer, but force a change when the failure thresholds are exceeded. That would be sufficient. The point of password changing to me is NOT to close the door again (because generally penetration once is enough), but rather to ensure that even the limited probing my proposal allows cannot be profitable, even assuming an attack lasts years. So, I'll grant you that monthly changes may be too frequent. Therefore have no forced changes until a failure threshold is reached.
If you choose to work it that way, then I'd add a third counter: failures per password. So, three successive failures is a lockout. Ten failures in a month is a lockout. Fifty failures since last password change is a forced password change.
Two part authentication is nice. But that isn't what the guy was asking. The guy was asking if username.password authentication can be sufficient. The answer is, yes it can. My post stresses that the greatest risk lies in inappropriate disclosure at the client. I think I was realistic throughout on the risks.
Password token cards and so forth are also vulnerable to deeply embedded attacks. If you have unauthorized software running on the client, then their recovery of passwords is the least of your concerns. If that situation exists, why bother recovering passwords? Just have that software read everything on the machine. If you posit a trojan program on the client, then two-part authentication won't help you. It's reading your data.
Note also that I recommend that you validate the address of the source. If a password is recovered and tried from an unauthorized locale, it fails as if the password had been changed.
So, if you are asking if a two-part authentication is superior, you bet it is. I'm just saying that a username/password system can be made reasonably secure.
You can strengthen the password system even more without a true two part system if you, instead of passing the password, calculate, say, an MD5 hash of the password, the client IP address and port and send that hash over the net. The server side uses the known password and the IP address and port it reads from the actual socket connection (this is assuming no proxy has interfered, but you can come up with something else). This way an attacker who has recovered the password must also either be on the server's network, or able to compromise every router between himself and the server.
I like this because even if the SSL is broken, nothing is learned that can be used in another attack from another location. The password cannot be recovered from the network traffic. I realize that this requires client side programming. Probably in Java (could you do this with JavaScript? I haven't used it enough to know...), which, of course, has its own risks; still.
Still better, have the server set a cookie on each connect that is used as part of the hash. The cookie is changed each time. If ever an authentication comes in that was not hashed with the last set cookie, lock the account. Somone got in there. Not only that, but it was the transaction just before the one that failed the hash. You've got the bad guy!
There are a lot of possibilities.
The person building this system has to decide if such an attack is likely and what the cost would be if such an attack were mounted. Look at what you are proposing:
Somone wants to read a doctor's e-mail so badly that he:
1) Manages to install software that can monitor keystrokes on a client.
2) Is able to pick out a password from all the keystrokes he has collected.
3) Is able to either directly connect to the client's LAN or the server's LAN such that he can impersonate a valid client IP, OR
4) Is able to compromise every router between himself and the server such that he appears to be the authorized client.
If such an attack is likely, then, by all means insist on a 2-part authentication.
If it's really important... (Score:2)
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.
Re:Suggestions (Score:2)
---
"'Is not a quine' is not a quine" is a quine.
Re:your finance records/transactions open to all (Score:2)
Here's the criteria: A vendor goes to their bank, gives their bank your account number and bank routing number. If questioned, the vendor may have to sign a statement that they have your authorization on file, but nothing more. In common practice, there is no actual verification of your authorization -- the originating bank takes the initiator's statement as your authorization.
As for penalties, it appears that it's on the same level as writing a bad check. If the vendor makes enough unauthorized transactions, someone at that bank might slap their wrist -- and send them along to the next bank. Pathetic and sad, indeed. I used to work (long ago) as a banking MIS drone, yet the more I deal with that industry as a consumer, the more I'm consistently horrified by the endemic negligence and resistance to new knowledge.
Re:Suggestions (Score:2)