It is becoming increasingly common for healthcare provider settings to leverage their existing physical access ID cards to transition from passwords to strong authentication. This paper will explore the reasons driving organizations toward this direction, but more importantly discuss the positive and negative attributes from a security standpoint. Core to this paper, will be to look at (and explain) the technical and policy aspects in the context of comparing the new system to their pre-existing password management program and endeavor to add clarity as to how both impact organizations capability to protect PHI. Also to be covered are some common objections and assumptions.
Replacing Passwords with RFID Cards: Is it an upgrade, or a step backward?
Industries often require different technical approaches to address their challenges due to the uniqueness of their business models and the demands that govern how they need to respond. Healthcare is no exception and perhaps fits this more than most others. (For more information on what makes them unique, see https://d6research.com/healthcareid)
They have to deal with specific regulations regarding PHI (Protected Health Information), which shows itself in many forms throughout their environment, from internal systems to external ones (Business Associates), all of which are highly regulated. Mandates are evolving and penalties are becoming stiffer to increase accountability in the event PHI does get out to the wrong hands. Passwords are a productive area for improvement, as they are both targets for hackers and a major point of vulnerability for even well-intentioned employees.
Healthcare is unique in many ways but in particular in its responsibility of the lives of those within the community it serves. It cannot just implement strong authentication and carry a big stick when users complain about its usability, as it must factor providing quality care, part of which involves the capability to do so quickly without unnecessary barriers at a cost that is justifiable. Slowing down a nurse or doctor in the emergency room by even a few seconds can have a major impact on outcomes.
It’s around here somewhere that very bad decisions get made – to replace existing passwords with proximity cards. The common justifications are:
• Cost: Stakeholders look to leverage existing investments like the card they have.
• Ease of Use: Users are already familiar with them. Touch and go. Likely few complaints.
• Security: RFID is not well understood and, to many, assumed to be secure.
• RFID Vendors: Typically lack insight into established IT security principles and policies.
• Validation: 3rd parties familiar with technical security of them are typically absent from process.
• Stakeholders: Doctors tend to override objections of security in favor of convenience.
In these instances, it is the assumption that after upgrading the authentication to RFID cards there has been a significant security improvement. Unfortunately, for the vast majority of organizations where they had a minimally acceptable password policy before the transition, it’s actually less secure than before. Let’s walk through this logic (and we’ll stick to what can be verified):
Current state of password management:
Most organizations have evolved over the years to incorporate best practices into their existing password management programs such as enforcing longer passwords, more complex ones such as alpha-numeric, forcing users to change them regularly (every 30, 60, or 90 days is common), and restricting previous ones from being reused, not to mention tools that automate password resets and help desk processes.
Replacing a password with another password:
What eludes many who do not have a technical understanding of how proximity cards operate is that it is not the card itself that authenticates to an application; rather it is what is stored inside the chip within it. Inside are binary strings of data (1’s and 0’s), which are essentially just numeric passwords. It is the same credential that is used to authenticate to the door and often referred to in physical access as a “card number” (and a facility code).
Since it is clear text (unencrypted, and can be easily read), users can go in and verify this for themselves using a basic calculator (type the binary string in and use decimal function to translate to a whole number). Note, “formats” attempt to obscure this password (only if part of the card number is being used and not the whole sequence), but these can be deciphered in an automated fashion with tools available over the Internet (or other means that employ manual techniques). The point here is that it is in reach of anyone who wants to do it, not an elite few who have advanced skills.
Note, all cards on the 125 kHz frequency, the most common type, have no protection of their data on them. When they were first designed, the goal was not security but rather reducing the cost and burden of replacing keyed locks. There are some high-frequency cards that use encryption to protect this number, and we’ll get to that later. For now we’ll model the following part of the discussion around 125 kHz since it outlines the fundamentals and is most common.
Breaking old rules and ignoring new ones:
Where it gets really interesting to the Information Security and IT community is when it is accepted that proximity card credentials are really an unprotected container for static passwords and then combine it with the common practices of the physical access market in how they are produced and distributed. Apart from very few exceptions, this “card number” (or password) is vendor-assigned (encoded by the vendor in its production facility or, worse yet, outsourced), typically recorded somewhere for later tracking (yes, they keep records of these numbers), packed up and shipped out to the customer. When they are received, a photo is taken, the card number is entered into the building access system, activated, and handed over to the user. By the way, the card number is typically printed right on the card itself, to make it easy for the enrollment officer to enter the number into the system (we’ll come back to this one)!
Unfortunately, while this process has historically been acceptable to physical access, it breaks some of the most fundamental principles in information security. The process is riddled with issues from the vendor assigning passwords and storing them, to having no disclosure as to the controls involving how these are stored as well as the chain of custody before it arrives to the customer. I don’t recall any other instances where IT would even entertain letting any vendors do this.
To put this in perspective, consider a different scenario in a similar context. If IT were to order new computers from Dell, and they arrived with the passwords printed on them (and could not be changed), would this be acceptable? No matter what the reasoning may be, one would be hard pressed to find any information security professional who would even consider it. In fact, I suspect that Dell would decline to do it even if asked to do so.
Overlooking this momentarily, there is another significant risk. IT organizations universally accept that it is best practice to protect the passwords they do have. In fact, many mandates in healthcare require this at a minimum by establishing a review of best practices in how applications should secure these passwords that protect access to PHI and document and audit to ensure it is being followed.
A unique, and often overlooked aspect to leveraging physical access cards is that the same password is stored in a physical access control system database in clear text and the vast majority of the time:
- Is not under the control of IT.
- Does not subscribe to the same application security principles, audit, or review.
- Is often set up using default privileged and administrator passwords (such as “admin”, “password” or even “blank”) making it simple to access the system with administrator privileges.
- Is not properly secured on the network or otherwise (if not on the network) and open to the most basic attacks.
- Seldom undergoes adequate penetration testing before released by the vendor and too often some of the “top 10” OWASP vulnerabilities are found within them begging to be exploited. See them here: http://tinyurl.com/k3snj9a. So, even if the implementation is strong, the application itself is flawed.
Once hackers get in, which due to the above is typically not very hard, not only can they access the card numbers but they know also know whom each one belongs to, even what the cardholder looks like, and additional information about their role and privileges. Through this, the security of IT just became dependent upon the lowest common denominator practiced by the two departments. This is a systemic organizational vulnerability and a complete failure in maintaining the security of credentials in any program. For more information, check out Chris Nickerson’s talk at DerbyCon 3.0 at Irongeek.com. This is really eye-opening stuff that every security professional should see. It is also pretty entertaining: http://tinyurl.com/lyg83ha.
Further, going back to basic pre-existing controls, the proximity password is not designed to be changed (it can be, but not on scale, and is more akin to a hack), so it remains static without any alpha-numeric characteristics it had previously. Perhaps the worst part of all of this is after one is compromised, and there are several ways to do this, the whole population is at risk due to the combination of how they are established, the design itself, and sequential numbering methodology that commonly accompanies it. While some limited measures can be taken, leveraging a pre-existing physical access card deployment for use in IT is more than likely to already have the very common practices in place that one would want to avoid.
Below is a chart that outlines basic password management principles that are commonly accepted in information security. It contrasts a typical program before migrating to proximity to that of one afterward in terms of capability of conforming in certain areas.
Considering the time, resources, and dollars it takes execute, the goal should be that most would be green afterward, and certainly not all red! Actually, most organizations that take on an authentication project tend to want to get away from passwords altogether. So where was the tangible gain if you’re still using a password and the problems are bigger than before under the hood?
Misconceptions and false security
The most common defenses by supporters of proximity cards for authentication in IT are the topics of using a PIN and possession of the card itself as a barrier to exploiting this solution approach. Regardless of these arguments, all of the information previously mentioned still stands on its own, which defies best practice and fails to be countered by these objections. The following are responses to those objections.
Common Objection #1: Using PINs in conjunction with a card to authenticate to IT systems:
The premise here is that the PIN is unique, only the cardholder knows it, and makes this card two factor. This is true, but put into context within its specific use case and environment, it shouldn’t earn the confidence of an information security professional:
- Proximity cards cannot store the PIN (given the security model, one would not want them to anyhow). However, this means that the PIN is associated with the card but stored somewhere else.
- Since the proximity card does not have a username, the PIN could essentially take its place. You are then back to username and password at best (and likely shorter and weaker ones since they are both numeric.
- PINs in this scenario are typically mapped to the user client software on the computer (endpoint) – not the back-end application or directory that interrogates the user.
- This means that while the client takes this approach, the back-end application where the valuable data resides, is still dependent on a weak password (and not the PIN or possession of the card itself).
Common Objection #2: User must have possession of the card:
After establishing that back-end systems and domains are dependent on a weak and static password and not the PIN, the correct statement would be that a user must have possession of the card if a) he tries to access the application from the rightful owner’s computer, and b) we assume that the client software is secure (which is typically not tested or validated, but that’s another topic for another day).
The takeaway here is that hackers do not limit themselves to gaining physical possession of targeted personnel’s devices, cards, and PINs, and shrug in defeat if they cannot do so. The data is in a system; hackers will continue to target that system in a variety of ways and exploit the fact that the only thing guarding it is exceptionally weaker passwords than before. And if one thinks they aren’t going to notice a pattern or sequence to them, think again. The bottom line is that this model is a fundamental design-level flaw if we are to look at it through the eyes of existing commonly accepted information security principles intended to protect valuable PHI that exists, where it exists.
This approach stores the existing application passwords in client software (some store them on servers, which may be a slight improvement) to be presented to an application when it requires them for authentication. They are typically stored encrypted, and the card number and PIN are used to decrypt them when they need to be used.
The upside here is that the user no longer needs to remember many passwords, and they aren’t changed to weak ones (card numbers). It also enables IT to change all of the user’s passwords to something incredibly complex, making it stronger than it was previously, since they no longer need to remember it.
Unfortunately, the master password that is now used to decrypt and permit use of the passwords is the weakest link – the proximity card number! Break that, and someone may then have access to all applications (and potentially the passwords). As for figuring the PIN out to do this, since it would be a local attack, there are a few methods to execute this, but we won’t cover this here.
All of the references to proximity thus far have been toward 125 kHz. There is a lot of confusion on the terms “Prox” and “Proximity.” “Prox” is a trademarked term and product from HID Global. It functions on 125 kHz. Proximity is not a trademarked product but rather a generic term that can be applied in various aspects but commonly refers to products using the 125 kHz frequency. Both function the same exact way with the exception of formats in some cases (how the bits are arranged) and perhaps engineering design in respect to performance. In other words, security is the same (doesn’t exist), but obscurity is different because of the formats used.
A common objection is that high frequency such as 13.56 MHz is much more secure and therefore acceptable to use for authentication to IT systems. We are not going to get into any specific technologies on 13.56 MHz because truthfully, vendors are quite sensitive to this, and secondly it doesn’t really matter at all.
Why? Because it is the same concept. Regardless of the fact that the binary string may now be protected with a cryptographic key, when it is stored on the back end, it is still a card number being used for a password. The higher-security card doesn’t do any more to secure it outside the card than the proximity card does.
If the card was being attacked directly, perhaps this might be more effective. However, remember, we are after application data, so why bother doing that anyway? Fundamentally, the back end is still weaker than before. Also, these high-frequency cards are breakable, and once this is done, they are reduced to the same approach one could take with a proximity card as they often use the same binary arrangements and card numbering practices as their low-frequency cousins.
There are some newer-brand RFID cards coming out that do not use formats but rather a data object of sorts. It’s quite hard to tell what is really going on because they don’t disclose it in reasonable technical detail. Based on this reason alone, since there is no validation, until it is known and tested against its claims, it should be avoided as well, especially coming from such vendors that have failed to follow best practices leading up to this latest iteration. Trust is earned through validation of claims, not by relationship or brand.
Compliance mandates are rapidly evolving to demand (or by incentive) that organizations increase their adoption of EHR (Electronic Health Records systems) and HIX (Health Information Exchanges) to enable improved care by sharing information across providers, payers and the patients. Initiatives such as Meaningful Use governed by HITECH legislation provide heavy incentives for providers to adopt these practices, and in 2014, Stage 2 deadlines loom to increase the adoption and depth of use along with it specifically outlining increased use of ePrescribing. They require improved practices in identity management and transaction integrity to better safeguard the increased depth of use and interaction of this information.
ePrescribing is rapidly growing on its own apart from any mandates due to the variety of established benefits it has on both practitioners and patients. However, prescribing controlled substances (such as Oxycodone and others that make up nearly 10% of all prescriptions) is now required under the DEA’s ruling for Electronic Prescribing of Controlled Substances to enable doctors to opt to prescribe controlled substances only if they follow specific measures that include approved identity proofing and authentication methods. RFID cards and/or static passwords are not on that list.
There are a slew of other mandates and initiatives that are taking shape to influence providers in healthcare to rethink how they proof identities, manage and credential them, and how they are used. In most cases, there are two recurring themes that come up as key considerations for anyone looking to implement a system that will be viable and scalable in the long term. First, credentials of the new system must be able to be repurposed across the various mandates to avoid creating multiple credentialing systems. Secondly, organizations must be able to demonstrate the credentials were implemented and operated in a way that complies with what other organizations require so they can participate in the various exchanges themselves.
RF Cards are their own trust model established by the vendor independently and have no standards frameworks that govern how they are to be created and used for authentication. Generally, it is an opaque operation, clouded in obscurity, with little peer testing to examine those systems or disclose reports of testing performed by credible third-party labs. Therefore, outside of the organization that implements them, they cannot be measurably trusted by another. In the age of mandates in healthcare where the basis is collaboration and sharing across disparate organizations, an investment in RFID for authentication to IT systems is inarguably not just insecure, but shortsighted. It will not scale, won’t be trusted, and is inherently insecure. Translating this into a PowerPoint slide in a business case review for a project, odds are it would have a hard time gaining approval.
Through improved policy, technology, and best practice, organizations can attempt to evade undesirable security events. However, many of the improvements concerning passwords have been common practice for some time and renewed efforts tend to lean more toward evolving away from them by considering alternatives that remove them entirely.
Somewhere along the way, since an RFID card visually looks as if it is not a password to those not familiar with them, it is too often overlooked that it is, in fact, a password. The lesson throughout all of this is that the only way to get rid of the password problem is to get rid of the password itself wherever it may reside.
While it is understandable that different departments may choose to implement technology in different ways as they consider the unique requirements of their environment, it is not acceptable to depart from commonly accepted information security principles when doing so. Organizations are free to accept whatever risks that they deem balance security and business requirements; however it should always be weighed against accurate information where the risks are clear and measured, resulting in a conscious decision to accept those risks as part of the program.
Copyright, 2014, D6 Research LLC.