| Email Password Reset [message #3223] |
Tue, 15 July 2008 02:38  |
 fredtrotter
Messages: 188
Registered: August 2006 |
|
|
|
Any plans on including this in future versions? This makes password support much easier. It would also mean that we could finally hash the passwords....
-FT
Fred Trotter, MirrorMed
|
|
|
|
| Re: Email Password Reset [message #3227 is a reply to message #3226 ] |
Wed, 16 July 2008 09:26  |
jdarren1024
Messages: 2
Registered: July 2008 |
|
|
|
| jay.walker wrote on Tue, 15 July 2008 16:08 |
To be HIPAA compliant they need to be logging in so many times per day
|
| jay.walker wrote on Tue, 15 July 2008 16:08 |
If you are using passwords which are not randomly generated then you are probably not being HIPAA compliant.
|
Can you cite any references to HIPAA regulations that support your statements ?
|
|
|
|
|
| Re: Email Password Reset [message #3230 is a reply to message #3229 ] |
Wed, 16 July 2008 16:14 |
jay.walker
Messages: 961
Registered: January 2008
Location: Tucson AZ |
|
|
|
| Quote: |
That does not mean they have login many times per day - they can login once a day during rounds and thats it. But I see what you are getting at - you are assuming users are all day users which is not always the case.
|
Yes, that is true and why I said generally. Further complicating this is if someone were to use an overall desktop login/logout unique to them with an inactivity timeout as is typically the case in enterprises but much more rare in physician offices. That overlaying system could probably meet HIPAA standards and allow a user to autosave their CH password in the browser and not require a CH level timeout.
| Quote: |
This is not *random* generation - I dislike having the computer decide my password. Rather this can be human decided following fairly common password rules.
My question was prompted as I often find it frustrating when the IT department 'decide' on what the HIPAA rules mean when it is often not their responsibility and sometimes they provide a rather dubious interpretation which adversely affects the usability of the system.
|
Note that I did say "probably", if you can get your users to self select passwords that are secure please share the secrets to that. I can say in our experience that lettings user select passwords results in weak passwords, it is that simple, with respect to "randomly generated" we generally like systems that create pseudo-pronouncable passwords such as temp-1Stormm, I would still call that randomly generated. I also agree that fully random passwords such as "1@445*^3jK" tend to result in users just sticky noting them on their monitor which really does defeat the whole enterprise.
A positive aspect to not hashing clearhealth passwords is that we are able to provide facilities with reports indicating the strength of passwords that have been selected. This type of reporting almost universally leads to implementation of psuedo-random passwords at the facility.
The thing that needs to be understood is that passwords can now be brute forced at astonishing speed and there are limited tools to prevent that such as rate-limiting and account locking but they present their own (DDOS) type problems. For commercial installations we always implement a second layer at the apache level which offers site or group logins and passwords before the actual CH password is reached, at least from outside locations.
Finally, as with all things HIPAA, your oranization needs to craft your own policy and with very few limitations whatever the contents of that policy is, so long as there is a written policy, will be deemed "HIPAA" compliant.
Thanks for asking those questions, I think this discussion will be valuable for a lot of people.
-Jay Walker
Customer Service
ClearHealth Inc.
|
|
|
| Re: Email Password Reset [message #3231 is a reply to message #3223 ] |
Wed, 16 July 2008 17:05 |
fredtrotter
Messages: 188
Registered: August 2006 |
|
|
|
The reason for having hashed passwords is not for security, but for access control and non-repudiation.
From a medico-legal standpoint if "opposing counsel" can show that it is trivial for an administrator to login as any user, then no action can be assigned to any particular, with any kind of certainty.
In order to fix this the system must
1. Assign an initial random password to a user, then force the user to change the random initial password to one only they know, on the first login.
2. Hash the password values in the database.
This is the "right" way to do this, and it takes a lot more than two lines of code.
Unless you have both of these in place, than an administrator can access the password text and then login to the system and perform actions "as" that user.
In short current ClearHealth passwords do not actually qualify as passwords under HIPAA. HIPAA defines a password as:
"Password means confidential authentication information composed of a string of characters."
The passwords in ClearHealth are not confidential because anyone who has Admin access to ClearHealth, or Admin access to the database can easily read them.
Obviously, there is little "security" benefit here. People who are trying to "break" in to the system are trying to get admin access, and this is a problem regarding those who already have admin power, but might abuse it.
The current code implements: "only your boss and you can login as you" rather than "only you can login as you".
Frankly, I cannot believe that this is not completely obvious that I am right about this issue. I am thankful, however, that I can now argue that this is not industry best-practice.
Please note test item SC 03.11 in the Final Inpatient EHR criteria for CCHIT 2008
"When passwords are used, the system shall use either standards-based encryption, e.g., 3DES, AES, or standards-based hashing, e.g., SHA1 to store or transport"
I hope that this settles the issue. I understand that being able to read the passwords makes administration much easier. But I feel that this is not the right way to run any system, and there enough people out there that agree with me that the issue is already at industry consensus, and really should be the default configuration option at least.
As for the enforcement of strong passwords, there is alot of debate about whether the benefits (harder to brute force) outweigh the disadvantages (far more likely that users write passwords down). The same is true with forcing regular password changes. However, it is also obvious that the availability of these features as a configuration option are also an industry standard. (See the very next CCHIT testing item: SC 03.12)
Now I can understand that you might see this, and the email password reset, as "not a priority for us" but would you take a patch for it from MirrorMed?
Regards,
-FT
Fred Trotter, MirrorMed
|
|
|
| Re: Email Password Reset [message #3232 is a reply to message #3231 ] |
Wed, 16 July 2008 18:04 |
duhlman
Messages: 654
Registered: February 2005
Location: Phoenix, AZ |
Site Admin
|
|
|
I don't want to beat this to death again so I will be as brief as I can and I think there is a good middle ground here. We aren't opposed to hashing and a psuedo-patch is included below. There are some other points I want to touch on:
1. "Administrators" are always going to be able to log on as any user. By virtue of that argument you would never be able to use open source and be compliant and in fact even in non open-source systems this is also true. Case law makes distinctions between "administrators" and users and realize that there is much more to identifying the activity of a user than just a login/password.
2. Hashes can always be reversed, it is just a factor of time and an administrator with information about salt can do this fairly quickly except perhaps with SHA256 and some others which are supported by very few systems. For most commonly used algorithms including MD5, and SHA1 reverse databases already exist though salting mitigates this a bit (again adminstrators would have access to the salt).
3. DES and AES are symmetric encryption and so an administrator would have access to the key and consequently have access to the passwords in plaintext. By virtue of their inclusion in the standard text you cited I believe that defeats your confidentiality argument on its face. Also note that 3DES is broken, on todays computers it is trivial to defeat no key necessary.
4. Interpreting confidentiality as meaning that an administrator does not have access I think this is a provably flawed (and noted in 3) and not inline with legal and industry standards. There is plenty of existing law which identifies system administrators in a different capacity from a regular "user". Also realize there there is a very large difference between what an attorney can argue and caselaw.
Simply put the introduction of email into the password equation for us is unacceptable. Email is the most insecure medium you can use to do just about anything. I cannot envision a situation in which this improves security as it introduces spoofing as a new and virtually unstoppable means of attack.
We would be open to some type of other web-based password recovery that would need captchas (though these are now broken), and 2 or 3 pieces of a security question type nature. I still feel that this is less secure than "Contact your system administrator" or for larger sites using remote authentication (see below).
ClearHealth supports remote authentication so you can very easily plugin to any kind of system you want to handle user/password management and recovery. This is intentional. Any large scale site is going to want to connect to their windows domain, or IMAP/POP, etc.
To initiate this you set the password to "!remote!" and configure or code the plugin of your choice. The forthcoming details on the universal DNS vulnerability show just how bad an idea it is to depend on email and domains for any kind of real authentication. To even begin to implement an email system with PHI you would need a system like site-key (see bank of america logins) which is patented and encumbered in a way that would be hard to reconcile with open source.
There is always going to be a big difference between perception of security and reality of security. If you implement simple sha1 hashing in a way that is configurable we would definitely accept that. Please use Celini::config_get .
Here is a patch that implements password hashing for those that want it, it may need a little tuning as I did not test extensively but note that it is just 2 lines. Consider it psuedo-code.
I think there are 1-2 other lines that would need to be updated with regards to users changing their own passwords.
Index: Base_User.class.php
===================================================================
--- Base_User.class.php (revision 5275)
+++ Base_User.class.php (working copy)
@@ -242,6 +242,7 @@
*
*/
function get_id_from_userpass ($username, $password) {
+ $password = sha1($password);
$sql = "SELECT u.$this->_pKey from $this->_prefix$this->_table as u where $this->_extraLoginTest username = " . $this->_quote($username) . " and password = " .
$this->_quote($password);
//echo "sql: $sql<br>";
@@ -322,7 +323,7 @@
*/
function set_password($password) {
if (!empty($password)) {
- $this->password = $password;
+ $this->password = sha1($password);
}
}
Sincerely,
David Uhlman
Customer Happiness Guru
ClearHealth Inc.
|
|
|
Members
Search
Help
Register
Login
Home
