I bet you are risking your company’s security — probably without even knowing it.
How we improved our company’s password management without sacrificing ease-of-use
The average company user has nearly 200 passwords to manage.
Now raise your hand if you share some of these passwords with your colleagues on a regular basis. Keep your hand up if you are sharing them securely. Are you sure, or have you posted a password in plaintext in an e-mail or chat before? No cheating! If your hand is still up, now answer me: Do you not only use unique passwords containing letters, numbers, and special characters for each and every account but also change them regularly? If your hand dropped somewhere along the way, you definitely want to continue reading. And if not, continue anyway. Improvement never hurt nobody.
The real problem why most organizations are at high risk of being hacked.
In 2018 Aadhaar has announced it had uncovered a hack compromising 1.1 billion user accounts. The first reaction of many users was angry response blaming affected providers for the resulting problems.
Still, the ugly truth is, there is no guarantee to hinder data breaches. Unfortunately, there is nothing that promises perfect security (yet).
Nevertheless, this does not mean, that companies can lay back and kick their feet up with the excuse that “100% security cannot be guaranteed so why bother”.
There are loads of things an organization and even individuals can do to protect their data and systems. The most important factor to take into account is how compromising one user account can affect all other user accounts.
Currently, users reuse their password at an alarmingly high rate, which makes it absurdly easy for hackers to gain control of high-value accounts.
Especially in organizations, it is common practice to have a set of passwords that are known between peers, and are reused for multiple services. Changing those passwords can be very challenging since they are not written down somewhere but rather just remembered by all the employees.
If a password doesn’t come to one’s mind, co-workers will go ahead and ask each other for the password of a specific service.
The standard response to that question is: “Did you already try <insert-company-password-1> or <insert-company-password-2>??”
Sadly, in 90 % of the cases, the password was indeed one of those two.
And even if sensitive data is stored in some central place, way to go! But have you thought about, that they are shared regardless of security via insecure channels such as email traffic or over a slack chat? This not only makes your credentials vulnerable, but more importantly this makes it extremely easy for attackers to overtake multiple arbitrary accounts. All the attacker needs to do is reveal just a single one from a targeted organization (i.e., via old emails or chat history).
When employees leave a company, mostly the passwords are not updated. If the employee left the company in anything less than mutual friendship those passwords are at high risk of being compromised.
And even with storing credentials into a password manager. Think about: What if it is necessary to share a password with some third party, that has no access to the internal IT service of your company? Even in such cases, sharing a password must be done in a controlled, and secure manner rather than just posting it into an email where it will be stored in plaintext onto the internet. Forever. No kidding, seriously.
To sum up the dilemma of nowadays organizations:
- For each account, a unique and secure password must be used.
- Passwords need to be stored at a central point, to guarantee all employees have access to current passwords upon changes.
- Sharing passwords between employees must be simple and secure.
- Individual access rights to the passwords have to be managed properly.
- Passwords must be (cryptographically) protected.
If you recognize similarities in how your company organizes passwords to the above description, you might want to consider continuing reading the next section.
How you can provide more security — without bending over backwards.
We, as wirecube, were facing the above-described problems but did not find a satisfying solution. Without hesitation, we decided to implement one ourselves.
The solution we were aiming for, should not only solve the security dilemma in a way which is easily accessible by our employees. It should also require low to zero effort for our IT department regarding permission management.
Our company was already using the issue tracking system Jira, where the permissions were already configured there. So we decided to implement a password management system as a plug-in for self-hosted Jira instances.
Another important factor why we decided to build on top of Jira was the accessibility; it is always annoying to open up an application when a password is needed. Hence all our employees have a Jira tab open all the time.
The resulting application we called SESAM.
SESAM is not only an integrated and reliable password manager but also allows secure transfer of passwords and sensitive data. The focus of SESAM lies in secure internal and external handling of passwords, to improve the security of your company.
The pillars of our new password management strategy:
- For each service, an individual secure password is used.
- Passwords are accessible among all employees, and the IT department does not need to maintain a permissions system since Jira permissions are already managed.
- We regularly update the different passwords, without the employees even noticing in most of the times.
- Anybody who needs access to a specific service knows where to find the information. There is no need to ask co-workers or the IT department for credentials.
- If a password is potentially compromised, we simply update it.
- Every employee has a private space in SESAM, where passwords, which are not shared, can be stored.
- SESAM provides a centralized search, where employees can search for usernames, URLs, description, etc. for easy access.
- If we need to share passwords, we just link the URL of the password in the Jira task or send it via any channel (Slack, Email, IRC).
Passwords are stored encrypted in the Jira database, even if an attacker would manage to dump the whole hard drive, the IT department does not need to worry about the stored passwords. (If you are interested in how we manage to accomplish that, take a look at the next section.)
If there is a need to share passwords with a third party (mainly customers), we can use a feature called “Time-Bomb Share.” Employees can generate a share-link to one or multiple passwords, that can be used either once or multiple times for a configurable time span. Once expired, the password cannot be used anymore.
It is now available at the Atlassian Marketplace.
The magic behind the security.
SESAM securely stores passwords on the server. Until it reaches the server, each plaintext needs to be encrypted. So that even if an attacker has the whole dump of the database and server files, he cannot read any meaningful data out of it. Hence, it must not be possible to access any plaintext password. Nevertheless, every user who has legitimate access to the password needs to be able to view it in plaintext. To accommodate these requirements, SESAM applies dual-layer encryption. Dual-layer encryption is the process of encrypting data more than once.
The starting point is the user’s master password, which is needed for password-based encryption. During the initial visit, the user registers to SESAM by entering his master password. Each time he starts a new session, the master password needs to be provided again. But since SESAM is integrated into Jira, we can directly rely on the Jira session management. So for each Jira session (each time the user logs into Jira), the SESAM master password needs to be supplied only once.
Using this master password, a key derivation function is applied in order to derive a symmetric encryption key called the Key Encryption Key (KEK). In theory, it would be possible to directly encrypt each plaintext password with the KEK, but practically this has major drawbacks. Most critically, such an approach causes major scaling issues, since it would require each password to be encrypted and stored for each user. Also, there is the problem that, initially, the password needs to be accessed in plaintext to encrypt it with the derived key.
To address this issues, another layer of encryption is applied using a Data Encryption Key (DEK). In general, each plaintext password is encrypted with the DEK using the AES-CBC-256 cipher algorithm. Hence, each password is only stored once in the database as a ciphertext. Consequently, to access the plaintext password, access to the DEK is required. Since only legitimate users should be able to access the DEK, the DEK is encrypted for each user using the users KEK. That means for each user an encrypted DEK is stored in the database. As a consequence, even if an attacker has access to the database, it is impossible to access plaintext passwords without the DEK. The DEK, in turn, can only be accessed with a KEK, which requires the attacker to know the master password of a user.
So summing up, decrypting a stored password works as following: The KEK, which is derived from the users master password is used to decrypt the DEK, which, in turn, is used to decrypt the plaintext password. To ensure additional security, private passwords are encrypted using a dedicated, user-specific DEK. Such a DEK is stored after encrypting it with the users KEK.
Hence, only the specific user can access the private passwords in plaintext. The Jira permission system is integrated into SESAM. This means the access to passwords can be limited to individual Jira users or Jira groups. Consequently, only those specific users or users within those groups have access to the passwords. Since configuring permissions for each password would be very time-consuming, multiple passwords can be grouped, and permissions are applied on a group-level.
This makes SESAM a great addition and a substantial security improvement to any organization already working with the Jira issue tracking system. SESAM can be used as a stand-alone password manager, and has been designed for teams and organizations that want to improve their security and be mindful of sharing valuable data.
Stay secure everyone!
