Over the past years, I got the chance of get in contact with many Laboratory Information Systems (LIS) available in the market.
And when I look back, and try to analyse them from a safe distance I get the feeling that they all have more similarities than differences.
They all share some common goals:
damn, look like a virus to me!!!
They all try to reach to different types of Labs, try to do different tasks, try to manage different business environments, try to adapt by all means to the circumstances, etc. And to do this they all seem to loose their vertebra.
Sometimes, it is wise to stop and accept that your software is not tailored to manage all the information concerning your lab.
Let me give you an example, a good clinical management software does not have to be a good stock management software.
Maybe your software is great for communications with lab analysers, but maybe it sucks for data mining.
And sooner or later, the Lab Manager will ask himself why is he carrying this huge, complicated, heavy, not flexible tool, when most of the time he only need a small tool, and only ocasionally he will need ‘the big stuff’.
Surelly he will wonder, “wouldn’t it be nice to modularize my software, use as I need, and hope my ‘modules’ communicate each other nicely?”
I’ve been in that (in)decisive situation over the past year. Between two house moves, managing family priorities among everything else, this blog has been stalled.
I’ve decided to try to give the blog a new chance.
Hope this is a good decision.
There was a generous reference to my blog, from DarkDaily that I’d like to share with everybody:
“Geek in the Lab
Pedro Fonseca has been an IT healthcare specialist for more than 15 years. It is clear while poking through Geek in the Lab that Fonseca is passionate about information technology as it relates to healthcare. “Geek in the Lab” is laid out so that IT professionals can keep up with the latest in healthcare technology, but it is written in a way that is accessible to the laymen. While many similar blogs are full of difficult to understand technical jargon, Fonseca makes sure his blog is easy for all readers to understand. Far from a “How To” advice column, “Geek in the Lab” keeps track of healthcare IT trends and offers observations on how they may impact the big picture. Fonseca’s “Gadget of the Week” gives readers a glimpse of the latest in IT tech.”
Thanks to Robert L. Michel and his team for such kind words and keep the good work.
In my last post I’ve stated that the login/password is not secure.
Maybe the problem resides not in the ‘technology’ but as many times on the human factor.
In fact, the main problem is not the login/password procedure, but the way you use it.
So, in order to study my customers passwords, I tried to create several simple rules to determine if the password used by them are easily crackable or not.
I have done this study using data from an hospital, and having a 400 user accounts.
Let me remind that although our software has several rules implemented for password management, we were asked to turn them down. This rules include:
- time validity
- minimum chars used
- time period for using the same password
- among others.
So, the rules I’ve come up with, are 10 very simple and common sense rules:
Rule 1: Verify if the users ever changed the password (12% didn’t, meaning that they still use the original random password assigned to them)
Rule 2: Verify that password is the same than login (4% use password=login)
Rule 3: Verify if the password is the Institution name (1%)
Rule 4: Verify that the password is the Application name (4%)
Rule 5: Verify if the password is the official employee number (14% use their official number, that is published in every institution document)
Rule 6: Verify if the password is between 1900 and 2009 (25% a year like password)
Rule 7: Verify that password is a 4 digit number, not like Rule 5 (5%)
Rule 8: Verify that password is the user first name (2%)
Rule 9: Verify that password is the user last name (1% use last name, although I haven’t tried maid name)
Rule 10: Verify if the password is a portuguese name (3% use Portuguese names, which I suppose to be children names, or wife/husband names)
This simple 10 rules, allowed me to crack 71% of a 400 user accounts password, meaning 284 user accounts.
I suppose that if I apply this rules to the same users on different applications, I would have got similar results, because the crackable passwords were personal data.
“Do you really think your health data is safe?”
Let´s ban login/password NOW!
I’ve been working in hospital labs for several years, and have followed the IT evolution in this sector. In the beginning, the lab was an isle, and the information was secure for the physical barriers. The network was restricted to the laboratory, and the access to the software wasn’t password protected.
Then, the hospitals began to connect the several ‘islands’, and implementing a centralized infrastructure.
It was the beginning of domains, and the first contact of the user with logins and passwords.
Then, rapiddly there was a proliferation of software, and each one had different logins and passwords. There was administrative software, clinical, image, lab, infection control, then appeared the intranets and portals, and when the user noticed he had more logins and passwords than he could possibly manage and memorize.
One of the first reaction from users was to unify passwords. But then, some of them had time limit, and others did not, and it was an Herculean task to manage all this info.
Some hospitals tried to implement Single Sign On, others tried to ease access through digital id cards. But the most common access control still is Login/Password.
And why should login/password be banned?
Because it is not secure!
To prove this I have made some tests attempting to figure out what the user password was in several databases installed in different hospitals.
The results leave no doubt that this method is not secure. More than 70% of the passwords were broken in the first 10 rules.
On the next post, I’ll describe the tests I made and the results I got.