The heylogin security whitepaper version 2 summarized

Our security whitepaper is finally available in this detailed version 2. However, with several pages full of technical details, it may not be suitable for all readers. Nevertheless, to help you understand what makes heylogin technically special, here is a compact summary for you.

The security whitepaper consists of 6 parts

1. Introduction
2. Basics
3. Authenticators and profiles
4. How to secure personal logins
5. Our overlay
6. A final summary

1. Introduction

This chapter is primarily about the problems of the master password, the primary source of protection of other password managers. The biggest problems are:

• Usability problems, for example, constantly typing the password and resetting it if forgotten.
• Security issues for users, as the master password is created and managed by humans, which makes it prone for cyber attacks
• Security problems for providers, which are shown for example with the LastPass breach last year

We have also explained the last point in more detail in this blog post on the LastPass breach, where all the important points from the whitepaper section are presented again in a somewhat simpler form.

At the end of the introduction, we explain how heylogin does away with this master password and replaces it with smartphone unlocking instead. For one, this method is 2-factor secure by design, and secondly, a hacking attack would not be feasible in this case, because it would require stealing every user's smartphone, which does not scale and is uninteresting for potential criminals.

2. The basics

The first part of the basics is mainly about the cryptographic algorithms used, i.e. Curve25519 for asymmetric encryption and a combination of XSalsa20 and Poly1305 for symmetric encryption. Additionally, Argon2 is used as a security mechanism.

In case this paragraph didn't tell you anything: Curve25519 and XSalsa20 are much more modern algorithms than the AES 256 used by our competitors and provide the basis for our end-to-end encryption. This ensures that even we as operators cannot see their data. Likewise, Argon 2 is the modern standard for thwarting criminals when cracking the encryption; many other providers only use PBKDF2 here (more info on our comparison page).

Subsequently, the naming and explanation of keys is discussed. Here it becomes very technical for the first time, the explanation forms the basis for the later chapters.

Keys: Roughly speaking, encryption works with keys that are exchanged between two or more parties. There are private and public keys. These keys ensure that only authorized persons have access to the data.

The second part of the basics is about our security architecture, i.e. the structure and the individual parts of heylogin and how they communicate with each other. Here, these individual components, i.e. the Mobile App (Authenticator) and the Web App + Extension (App) are not descibed in greater detail for now, as this is reserved for a later chapter of the whitepaper.

3 Authenticators & Profiles

This section deals with three topics:

• The smartphone as authenticator (as well as alternatives to the smartphone).
• The backup options
• Profiles as a bridge between Authenticator and Apps

Authenticator

The smartphone is the authenticator that every user has. The secure element built into every smartphone plays a crucial role. It not only stores security-relevant data such as PIN, FaceID or fingerprint, but also generates the secret from which the data is encrypted by heylogin.

Besides the smartphone, even more physical devices can be used as authenticators, for example tablets or Yubikeys, devices that also have a secure element.

Backup options

This gives rise to various backup options. As a solution for organizations, the easiest backup option is to restore through an organization admin.

We also use the device backup function of Android or Apple, as these are stored securely end-to-end encrypted and only the user as the original owner can access them.

In addition, we also offer backup via backup code generated in the mobile app. While the previous method only works with the same mobile operating system, i.e. Android to Android or Apple to Apple, the heylogin backup code allows you to transfer your account across platforms.

Profiles

When multiple users interact with each other, for example when sharing logins in an organization, the app used to have slower response times due to the large number of authenticators per user (they all have to be synchronized and adjusted every time a shared login is changed). Profiles were made to solve this issue.

Profiles do not have their own login functions and act more as a kind of bridge to which both the authenticators on the one hand and the app on the other are linked. Now, if something changes in the interaction of users, i.e. login data or number of members in the organization, it only needs to be reconciled with the profile of the individual users, not with each authenticator.

4. How logins are secured

This section deals on a very technical level with how heylogin works. The topics are:

• Storing and reading logins
• Connecting new devices
• Locking and unlocking devices
• Organizations and admins
• Account recovery

Saving and reading logins

Logins consist of several parts:

• Username or Email
• Password
• Web page

This information is stored encrypted in a so called vault, all data is extra encrypted. These vaults are stored on the server, but they are only decrypted by the authenticator of the corresponding users.

Connecting new devices

Once the mobile app, i.e. the authenticator, has been set up, other devices can be connected. The simplest variant is connecting with one or more browsers via QR code. In this case, a key is exchanged with the Authenticator via the QR code to enable encrypted communication between the devices. For technical details, check out section 4.2 in the whitepaper.

Locking and unlocking devices

The Authenticator adds an encrypted Authenticator seed to a session when it is unlocked (for example, in a connected browser), and removes it when it is locked. The session cannot store the seed, only temporarily store it and remember certain data that can then be displayed in the overlay on a web page.

Organizations and Admins

Organizations are the main application area of Profiles, as this is where users interact with each other. In addition to the "personal logins", user vaults created specifically for the organization, teams can be created, which are vaults that can be accessed by multiple users. Admins play a special role, as they not only have recovery options but also have the organization linked to their profiles.

Account recovery

The best and easiest option in case of loss of one's push authenticator is to contact the organization admin. This person can decouple the old authenticator from the users so that they can then set up a new authenticator. In addition, both backup options discussed in Section 3 are also valid methods for restoring his account.

5. The overlay

Thanks to Extension, an overlay is displayed in the browser, which drastically simplifies the use and the steps required to log in. With one click, and if necessary a swipe on the push authenticator to unlock, you are logged in. In doing so, the normal login form of the website is hidden, everything is filled in automatically on click. This also works with 2-factor secured account via TOTP (we have several articles on this in our blog as well).

6. Summary

In the whitepaper we presented:

• how heylogin works, especially the relationship of authenticator (smartphone) and app (web app + extension) as a 2-factor solution
• how the stored data is encrypted
• which backup options heylogin offers
• how organizations work
• how the overlay works

For more details please have a look at our whitepaper, if you are already convinced feel free to start with heylogin directly.

‍

‍