HIPAA-Compliant Login: The Law and the Tech
By Adrian Lăpădat
January 21, 2022
HIPAA’s principles of flexibility, scalability, and technology neutrality give covered entities and business associates leeway on login implementation. Though navigating them can be like opening a can of worms. What can one do to construct a HIPAA-compliant login?
The answer lies in §164.312 of HIPAA, the “Technical Safeguards” section of the Security Rule. This section contains guidelines on access control and person or entity authentication when it comes to protected health information (PHI). Knowing this rule gives context when choosing a secure login for your company so it may properly safeguard PHI and meet HIPAA compliance.
HIPAA Technical Safeguards Overview
HIPAA’s “Technical Safeguards” section has five subsections, of which the subsections on Access Control and Person or Entity Authentication are the most relevant to be aware of when implementing HIPAA-compliant login.
Access Control Standards
This standard means establishing policies and procedures for access to information systems. Access control encompasses giving persons or software the minimum information necessary to complete their tasks, and ensuring that only authorized persons or software have access. HIPAA provides four implementation specifications for access control:
1. Unique User Identification (Required)
Assign a unique name/number to identify and track user identity. Consider how login software will interact with the company’s systems and software.
2. Emergency Access Procedure (Required)
A covered entity should develop contingency plans to access electronic protected health information (EPHI) in an emergency. These can include situations where the covered entity does not have access to electrical power or where the previous individual with access to critical EPHI is suddenly unavailable. This may involve switching permissions and other backend work. Consider discussing this with the company’s login provider.
3. Automatic Logoff (Addressable)
Consider implementation, feasibility, and time limits. A computer in a room not accessible to the public may not need time limits.
4. Encryption and Decryption (Addressable)
Encrypt or decrypt EPHI. On the login side, this is relevant to whether the covered entity or business associate implementing login is able to encrypt the information they use. Since all individually identifiable information is considered PHI, many patient usernames could be PHI. You may also weigh different methods of encryption; some are astronomically harder to crack than others.
Personal or Entity Authentication Standards
Verify that the person or entity seeking access to EPHI is the one claimed. This is the primary purview of login, and different means to accomplish this are shown below.
Note: “Addressable” specifications give the covered entity or business associate leeway. You can choose to implement them, implement alternative measures, or not implement them. As always, your choice must be documented for record-keeping and audit purposes.
HIPAA does not specify what kind of login a covered entity or business associate should use. To develop HIPAA-compliant login, address HIPAA’s Person or Entity Authentication Standard and the Access Control Standard’s Unique User Identification Specification.
Username and Password
Since HIPAA is technology neutral, a best practice for HIPAA-complaint login is to follow guidelines from federal regulatory bodies like the National Institute of Standards and Technology (NIST).
- Password length is more important than password complexity
- Don’t enforce regular password resets
- Screen new passwords against a list of compromised and common passwords
- Let users paste passwords
- Enable “show password” while typing
- Limit number of failed login attempts
- Implement two-factor authentication (2FA)
- Salt and Hash passwords
Here’s the problem with passwords: more than two in three people reuse passwords, and most Americans use weak passwords. Even the tougher nuts can be cracked, and there are plenty of ways to do it. They’re one of the weakest ways to protect accounts – 80% of data breaches in 2018 were caused by password compromise.
When it comes to passwords, there are several safer alternatives.
With MFA, logging in requires more than one set of credentials. The most common form of MFA is 2FA, where a user logs in using two sets of credentials. Any form of MFA is safer than single-factor authentication, although some, like a physical key or biometric credentials, are more hacker-proof than others.
humanID does not store any user information. To confirm user identity, as per HIPAA standards, a phone number is required upon login. Though after confirmation, this number is immediately hashed and deleted, becoming untraceable back to the user. Unlike encryption, where data is meant to be decrypted, hashing is a one-way street: hashed data is not meant to be decrypted.
To elaborate, humanID takes a user’s phone number, salts it, and irreversibly hashes it via a hashing algorithm called SHA-512. To salt means to sprinkle random values into an input string, in this case the phone number. Once hashed, the addition of salt makes the original number unrecognizable, and thus makes decoding these types of hashes extremely difficult. If a hacker were to crack into humanID, the information they receive would be useless: it would only be a collection of salted hashes.
humanID provides added convenience along with its high level of security. To log in with humanID, users need only remember a phone number. Moreover, humanID is a single sign-on, so users can gain access to multiple platforms with one humanID login. If a platform that uses humanID is compromised, it would not compromise another platform because humanID gives users unique hashes for every platform they use.