The difficult question of our digital life security has only become more complex over the years, due to our increasingly massive use of all kinds of digital content. As the financial stakes behind our data can sometimes be colossal, it is normal that from the beginning they have aroused the greed of all kinds of unscrupulous people. And it goes without saying that, even if all kinds of mechanisms have been put in place to better protect our data, the techniques to steal it have never stopped growing in ingenuity.

There are already many guides out there discussing what differentiates a good password from a bad one, why it is needed to enable two-factor authentication when possible, or even how to use a password manager. All these tips should satisfy the vast majority of users, who generally only want to access their messaging service or their favourite social network without too many constraints. Compromising of those different accounts may not seem very serious as it usually boils down to a few annoyances to fully recover them. Even the hack of a banking account like one on PayPal may seem to have a limited impact as the organization offering the service watch your back and can block or refund the illegitimate fund transfer.

For all of these users, I’ll just advise sticking to the basic rules of thumb:

• to use a password manager aimed at storing a strong and unique password for each account;
• to activate two-factor authentication;
• to have an up-to-date antivirus;
• to beware of phishing techniques and other various scams.

But if you keep reading, maybe are you part of a minority of people who see the shortcomings inherent to this minimalist approach. Perhaps you feel the need to protect data for which “pretty much secure” is not enough, or perhaps you have to cope with constraints that go beyond standard use cases.

To fix a concrete case that everyone will understand in 2021, let’s imagine that you are the cryptocurrency millionaire that I could have been if I had been a little more visionary. This technology is based on the usage of a public and private key pair, the latter being essential to spend your money. Here, there won’t be a PayPal that will come to your rescue if you lose your private key or if someone steals it and pluck all your money out of your account. Here, you are alone.

Of course, in this very case, you will not have missed investing in an electronic wallet to prevent your private keys lying around on a potentially corrupted PC. But the problem is far from being solved: this wallet can be destroyed or lost by accident and you will therefore need to set up a mechanism to save your recovery phrase. The recommended method is then to engrave it in a metal plate and put it in a safe (ink and paper are very fragile and deteriorate over time). This procedure is safe, but not very convenient. Also, if some people follow this path to protect their cryptocurrencies, I doubt that they will follow it to preserve other digital data as well. I’m also pretty sure that many will simplify some security steps to make their lives easier, thereby increasing their vulnerability. Then, finally, do you really want your assets to disappear with you if you happen to die unexpectedly ? Wouldn’t you like your spouse or children to be able to benefit from your crypto-currencies ? Because the problem is that it will definitely not happen if you have not provided a dedicated mechanism or instructions to do so.

This is just one example among others, but it has the merit of being an obvious one. Crypto assets are indeed good representatives of data that we want to protect particularly well without making it completely inaccessible. Cybersecurity is thus a difficult question to resolve and it certainly requires devoting a little time to think about it peacefully, to deal with your own constraints and objectives. For my part, it took me a big day of thinking after having watched a very good video by Charles Hoskinson that I would like to thank here. It sparked my interest, but above all it gave me a lot of tips and tricks that I will use again here.

The Disponibility (D), Integrity (I) and Confidentiality (C) Triad

A good IT security solution must inevitably be based on the three pillars of availability, integrity and confidentiality. Without going into too many details that others will explain better than me, these concepts can be applied as follows for the management of our passwords:

• Disponibility: information must be accessible to whom it may concern when it is needed. The whole problem then comes down to making our passwords available while ensuring their integrity and confidentiality. For example, if you write this information down on Post-its pasted under your keyboard, the information is very available, but also strongly jeopardizes the other two criteria.

• Integrity: this criterion assures that the data to be protected is not altered or destroyed whether voluntarily or involuntarily. In our case, this amounts to ensuring that the passwords are stored in a secure place with adequate backup copies.

• Confidentiality: passwords should only be accessible by the person who uses them, i.e. you. Increasing the measures ensuring this criterion can considerably deteriorate that of availability. For example, if the information is recorded in ledgers stored at the bottom of a safe in your bank, its use will be very confidential, but also severely limited.

As we can see, improving each of these criteria in isolation can have a negative impact on the others. It is therefore necessary to find a compromise depending on the requirements and constraints of the system to be protected. There is no perfect solution, every situation is unique.

Anyway, you will notice that I have tried to cover as many cases as possible when you discover my little roadmap below. So even if it might not be 100% applicable to your needs, chances are it could be as a very good starting point.

Requirements

The requirements relating to password management that I wanted to put in place are quite numerous and are not trivial to satisfy all at the same time.

1. No sensitive data can be stolen without compromising, at a minimum, two layers of security. By security layers, I mean any mechanism that stands as an obstacle between a hacker and the data to be protected. This can consist of a firewall, email account, access to your personal computer, access to your phone, password, two-factor authentication, etc. Of course, not all of these layers offer the same level of protection and each sensitive piece of data should be considered separately to determine if an additional level of security is not required.

2. The password manager itself is considered as a layer of security that can be broken. We will come back to the use of such software later. It is meant to facilitate management of confidential data by keeping them safe in one place, in a sort of encrypted digital safe. Due to the underlying cryptography that is used, this kind of solution offers almost foolproof protection when the safe remains locked. However, the problem stems from the fact that in order to be used, this safe will have to be open from time to time, potentially exposing all of its contents to a rogue spy lurking in the shadows. And although various mechanisms are often put in place to guard against malware that would try to steal information once the database is unlocked, it is absolutely impossible to guarantee that only you will get access to those data.

3. Any device, whether it is a phone, a PC, a USB key or other, can be lost without consequence. They can also be all lost or destroyed simultaneously without it being impossible to recover all your data and accesses. So even imagining the grim scenario in which your whole house would go up in flames, taking all of your electronic equipment with it as well as your pseudo-fireproof safe, you must be able to recuperate everything. This criterion is essential knowing that any instrument supporting you in the implementation of your security policy can be easily lost, stolen or destroyed.

4. The solution must be as flexible as possible and must allow daily access to the various passwords from a working computer. The problem then arises from the fact that a computer exposed to the Internet daily is very likely to be corrupted in one way or another, even by adopting a careful behaviour. It is therefore not impossible that a keylogger records everything you enter from the keyboard or that a hacker can see what is displayed on your screen. From having personally played with Back Orifice at the time, I can assure you that it is not science fiction at all. Despite everything, unlocking your password manager exclusively on a PC disconnected from the Internet is certainly prudent, but also terribly disabling. So we won’t do that most of the time.

5. Lastly, the policy put in place must provide room allowing you to pass on your password database to a relative if the worst should happen.

Shopping list

The most important rule to consider when building a security policy is to realize that no solution is infallible, but that the more you have to break protections to penetrate a system, the more the difficulty exponentially increases. Compartmentalization is therefore compulsory in order to prevent a breach from spreading and nothing and nobody should be trusted. The expression “belt and braces” is the norm here.

The ingredients that we are going to use are fairly standard, but it is above all in the right way to combine them that the effectiveness of a solution lies. So let’s start by listing the different elements we are going to need:

1. A password manager to bring all sensitive data together in a single digital container. The use of such solution goes, of course, completely against the principle of compartmentalization that we have just mentioned. And knowing that we consider this piece of software as not entirely safe, additional layers of security will be necessary to avoid literally putting all our eggs in one basket. Such a tool, however, greatly facilitates our requirements 3 and 5. Indeed, It allows us to focus our attention on a single thing, as well as to make creation of backup or synchronization in the cloud easy. Leaving passwords lying around is the best way to lose them or to end up with uneven protection. A manager also offers the advantage of being able to memorize all kinds of long and complicated passwords, as well as offering tools to scramble keyloggers.

2. Unique passwords for each account to be protected. This principle prevents that if a password were to be compromised, all your other passwords are also compromised. Remember, when you protect any online account with a password, you have no idea how it will be handled by the service provider. Normally a password should never be stored unencrypted on a server, but it is still very common that this is not the case and that hackers take in their loot databases of thousands of passwords. The first thing they’ll try next is to reuse them with as many other online accounts as they can.

3. Strong passwords to guard against all kinds of dictionary or brute force attacks. A password based on a variation of any existing word is trivial to crack nowadays with appropriate software. But even completely random passwords are at risk if they are too short. Indeed, brute force attacks that amount to testing all possibilities as quickly as possible become more and more realistic. The disproportionate power of certain graphics cards can even be used to achieve dizzying test rates per second. As explained here, the RTX 3090 allows for example to test more than 3 billion passwords per second on an encrypted ZIP file. A quick calculation then makes it possible to realize that a short day is sufficient to bypass any password of 7 characters or less. The use of managers allowing the memorization of long random passwords is therefore one of the best weapons we have at our disposal.

4. A Yubikey. This one offers the possibility of transferring part of your access control security on a hardware device much more reliable than can be your computer or your smartphone. The first usage we will make of it is to split the passwords into two parts, one of which will be stored in the key. This makes it possible to create very strong passwords that you will not even have complete knowledge of. Accessing one of your accounts will then require two elements: one that you memorize or that will be stored in the password manager, and a second that you bring through this key. In addition, the Yubikey implement all kinds of very secure cryptographic protocols enabling best in class two-factor authentication. Those devices also have the advantage of being very easy to use and are accepted by more and more service providers.

5. A USB key running a Tails session. Tails is an operating system based on Linux, but which is built in such a way as to make all your activities anonymous and to leave no traces after your passage. Its great strength lies in its mode of operation that is carried out entirely in the host computer RAM, without any file ever being modified on its physical medium. Therefore, even assuming that you have collected various cookies, viruses or other unscrupulous cookies during a session, all of this will be purely gone the next time you use it. Tails indeed always starts from a completely virgin system and offers the near certainty of operating on a totally secure computer. Technically, all that is required is to download the image of Tails and to flash it on a dedicated USB key. Then, any computer can boot on it. Although not inherently difficult, launching a Tails session may seem restrictive for an everyday usage. Also, as stated in requirement 4, we will only use it for some very special and infrequent operations.

Choice of a Password Manager

There are many password managers with varying features and prices and to make a choice may then seem difficult. The level of security they offer isn’t really a distinguishing factor, as all of them employ more or less the same kinds of techniques to encrypt and protect your data.

Most of them revolve around a cloud service that will be either very limited or paid (delete as appropriate), a pleasant user interface and all kinds of features to make their use very easy and almost transparent. Because of their simplicity, they are also the kinds of managers I would recommend to anyone not reading this article or who has given up along the way.

But if the data you manage are very sensitive or very valuable, do you really think it’s a good idea to place them in the hands of someone else who will have no accountability if something goes wrong ? While it’s unlikely if they do their job well, it is still possible that your data will disappear in the fire of the data centre that housed it (yes it happens). All you will get then is a vague apology for the inconvenience - and you will only be charged $5 a month :-).

Personally, I prefer the completely free option, but a little more technical, that the manager KeePass represents. The latter is very solid cryptographically speaking, entirely free, audited, and will give you the joy of tasting a graphical user interface back from the 90s. Clearly, it is not what one could qualify as user-friendly and it will certainly not take you by the hand to simplify your daily life. However, it is extremely powerful and you will remain the sole depositary of your data; which to me is all that matters.

Setting up a Solution

Now that we have everything we need, it time for us to start cooking the dish I promised you. To do this, let’s first look at the recipe that you will find in the image below.

The main ingredient occupying the entire central part of the drawing is obviously the password manager in which you will write down absolutely all the information you want to protect. The only thing that you will not be able to enter is, of course, the Master Key that is needed to unlock it, and its elaboration requires a little care.

Master Key Derivation

There are, of course, several ways to do this, but here is the one I use in order to have a password that is both very strong and very easy to recover. The idea is to start with any Root Code that is easy to remember. In fact, this will be almost the only information you will need to memorize. This code doesn’t have to be very complex, because we’re not going to employ it as is, the idea is rather to modify it through a secret derivation mechanism which will make it much more convoluted.

Also, you can see on the drawing at the top left that the Root Code is transformed to generate a Salt which will itself be saved in the Yubikey for convenience. This derivation procedure is a kind of secret to remember and may consist of various logical or cryptographic operations readily available online. Here is a non-exhaustive list of functions that can be used:

• Hash functions such as MD5, SHA or Keccak;
• Encoding change to or from hexadecimal, Base64, etc.;
• Various and varied permutations, shifts or rotations;

And of course, you can nest these functions together to create a complex secret derivation of your own. To fix the ideas, suppose that we choose 12345 as the Root Code, which is to say one of the least secure passwords we can imagine. Now let’s select the following derivation function (obviously, don’t choose the same one!):

$$SALT = SHA1 (REV (B64 (12345)))$$

Which means that we encode the string 12345 in Base64, that we read the result backwards, then that we take the SHA1 hash of the outcome. It may seem like it’s complicated, but it isn’t that much and it can be done in minutes with good online tools. It is also very easy to get the same result from the command line in Linux:

rc=12345
echo -n $(echo -n $rc | base64 | rev) | sha1sum

Then we get:

SALT = c25061cd9ec4fe948926caeb0d75ec1b5c3dace8

which is immediately something much more difficult to guess.

It goes without saying that you will neither be able to remember such a string of characters on your own, nor even to encode it easily. This is why we can use one of the very practical functionalities of the Yubikey and which consists in programming it to play back this sequence when you press and hold its central button, as if you had typed it yourself on the keyboard.

The master password is made up of the concatenation of this salt with the root code. This way, you make sure you have a password that cannot be brute force broken and no one could do anything with your Yubikey since one would only have half the information he needs to open your password manager.

Finally, and this is very important, you risk absolutely nothing if you lose your Yubikey, since you know the process to recover the embedded information. If you are afraid of forgetting it, have the formula engraved on a metal plate and put it in the safe. It will still be valid if you later decide to change the root code to something a little more subtle than 12345.

Password Management Methodology

Each of the information that you will store in your manager is unique in terms of value, frequency of use or associated level of security. Therefore, they do not all have to be treated in the same way and I will try here to outline the method I have chosen to apply. I will, of course, leave it to you to adapt it to your own convenience.

The pwd/code/sensitive information block of the drawing represents some password to be protected in the manager and the first step consists in filtering it according to these 3 main categories.

1. First, there are passwords that protect online accounts. These are accesses, such as your e-mail account, which are extremely exposed since the whole world has the opportunity to try to force the entry. They are processed by the <Public Gateway?> block in my flowchart and require special attention, because, if someone were to steal one of them, they could a priori directly access the associated resource.

2. Then there are passwords that are linked to some hardware device, such as your bike lock, your SIM card PIN, your phone or PC password, etc. These are in principle less vulnerable, because a hacker could do absolutely nothing with them unless they also get physical access to the associated resource. These are handled by the <Bound to device object?> block in the flowchart.

3. Finally, there is the information that does not belong to the previous categories and that has an intrinsic value in self, such as the recovery phrase of your crypto wallet. These are particularly critical and require a more thorough approach, because, remember, it’s not impossible for someone to steal the data in your manager when you open it. An additional layer of protection is therefore essential and this point will be dealt with later.

Handling Two-Factor Authentication

If it is an online account, then the next question to ask yourself is whether it has a two-factor authentication mechanism that you will certainly have activated, shown by the block <Dbl Auth?>. An affirmative answer immediately adds a level of protection, because the associated password is of no great use alone. However, be careful that several two-factor authentication methods exist and that they are not equal in terms of security.

First of all, avoid like the plague the famous and ridiculous secret question, whose only level of defence relies on a banality such as the colour of your eyes. If you are forced to enter something like this (unfortunately it still happens), either type in random garbage or consider it a second password that you will also add to your manager - perfectly, the colour of my eyes is sldk3g1hj4uhzeufi.

One-time codes sent by SMS are also to be avoided, because it turns out that this communication channel can be quite easily exploited to divert the transmitted messages. It’s best to use unique codes generated by an authenticator app like Google Authenticator, although this latter isn’t foolproof either. Indeed there are malware which would have the capacity to extract the secret seed of this kind of application if they managed to penetrate your phone. You must also be careful to save this seed in the password manager in order to be able to restore this access in the event you loose your device; we’ll talk about that right away.

If the website allows it, the best two-factor authentication method is actually a hardware security key like the Yubikey. It incorporates many protocols to generate one-time passwords that it is not possible for an attacker to steal. The only problem with the Yubikey is that you can lose it, and there are two solutions to handle this situation. The first, which is the one generally recommended, is to have 2 Yubikey both associated with your accounts. One of them must be stored in a safe place and only be used if the first one is lost, just for the time of buying a new one. The disadvantage of this technique is that it does not fit my requirement number 3 which states that all electronic material can be lost simultaneously.

Personally, I prefer to activate two two-factor authentication methods if possible: a first with an application such as the Google Authenticator and which will only be employed in case of emergency, and a second with a Yubikey which will be used daily. The loss of the latter is therefore no longer a problem, because the phone application can replace it if necessary. Additionally, if you are really worried that malware could slip into your phone and steal the seed from the two-factor authentication app, you can simply remove that access from your device. As this seed must be saved in the password manager anyway, you can always restore it later if needed.

Now we have to explain how to go about saving the seed of the two-factor authentication application. To do this, let’s start by looking at how the binding works on your phone, with the image below. In all cases, you will be invited to open the application and to scan the QR code that appears on the screen. This one actually contains a randomly generated secret seed that will be shared between your device and the online account. This is this very seed that must be saved in the password manager in order to be able to re-establish this link in the event of loss of the smartphone.

There are two schools of thought, as some web sites will immediately show you the seed in text form (on the right), while others will keep this information hidden (on the left). In the latter case, it is always possible to force it being displayed by clicking on the link enter the code manually. Another option is also to take a photo of the QR code and to save it in the manager as an attached file. In any case, this code will no longer be available once you have scanned it, so you must not omit to save it at this stage. If you forget or make a mistake, don’t panic: you can always remove a two-factor authentication method and restart this process.

Choosing a Password

Choosing a password is not to be taken lightly, but the constraints involved really depend on the use case. This is why I distinguish 4 cases in my flowchart, represented by the 4 green rectangles.

Let’s start with the two on the left, which correspond to online accesses for which no two-factor authentication is available (<Dbl Auth?=No>), but which would, however, be sensitive in terms of negative consequences if it were to be compromised (<Sensitive?=Yes>). This is certainly not the most common case, as two-factor authentication is normally available to handle these kinds of accounts. Nevertheless, I am dealing with it for the sake of completeness, but also to present again the method based on the salt, as this one is always interesting to use.

As we have the Yubikey to memorize for us a complex sequence and which is already used to unlock the password manager, we might as well reuse it in order to proceed in the same way here. The password will therefore consist of two pieces, one generated by the key, the other which will be stored in the manager. For example, if you choose 12345 again, you can store {SALT}12345 in the application to make it crystal clear to you. But even in the event that your manager is compromised, the real password will not be revealed.

If two-factor authentication exists, then we can join the path coming from passwords linked to some hardware resource. These two cases indeed present an additional level of security and we can possibly proceed without the salt technique seen previously. But whether it is with or without the salt, I still distinguish two possible cases in the flowchart, through the <Daily use?> block.

If a password is not often used, then it is fine to generate it randomly using the password manager and let the latter remember it. When you need it, you just have to take it from the manager and this is what I call complex pwd in the diagram. But for all kinds of reasons, it can be restrictive to have to open the manager every time you want to access a frequent application, or if there is no way to copy paste a sequence of 40 random characters.

So it is sometimes wise to relax a little our constraints which are in any case already of a good level. This is what I call simple pwd in the diagram. Be careful that I don’t mean that such password should be easy to guess, but rather that it should be easy to remember, while being unique and having a complex appearance. Then, you can use it everywhere without difficulty and without too much risk. I will not discuss here the different techniques to elaborate this kind of good password, because I realize that this guide is already very long and that I still have a lot to say. So I’ll just point to other articles, like this one, or even this other one.

Critical Passwords Management

As mentioned above, there is one category of information that needs to be taken care of and that does not relate directly to an online account or to any piece of hardware. Having intrinsic value, and assuming that the password manager is not foolproof, it needs additional protection.

This is typically the case with a cryptocurrency wallet recovery phrase, for example, because anyone with that information will be able to access your digital holdings. But there are other scenarios and one of them is a piece of data that we have already covered above ; the seeds of two-factor authentication applications such as the Google Authenticator. Indeed, if you store the master password of an online account in the manager, you cannot store the information related to two-factor authentication in the same way in the same place. Because if the manager were to be corrupted, these two pieces of information would be disclosed simultaneously.

We can thus imagine all kinds of more critical information that cannot be found as is in the password manager. And to find out what requires these extra precautions, it suffices to ask the question: “what would happen if someone could see the entire contents of my password manager? What could he do with it? “. The answer will then be obvious.

A first option to solve this problem, simple, but that I do not recommend, could be to embed a secondary KeePass archive inside the main container. The second would thus aim to store critical information in an independent digital safe with its own key, thus avoiding revealing anything in the event of an intrusion into the main container. But if it seems interesting, this approach has several flaws:

1. If there is any backdoor in the password manager (the kind that the NSA is sometimes suspected of trying to introduce where it can), then this second encryption will exhibit exactly the same weakness and will not provide any additional protection.

2. Accessing this second container is done exactly as with the main one: you have to open it to access all of its content. But as we have seen, it is not possible to guarantee that there is no malware lurking and waiting for this moment to strip you. And since we’re talking about much more sensitive data here, it would be very inappropriate to attempt to access it on your primary computer. In other words, this means that this second safe could only be handled on a computer secured with a solution like Tails. This makes its use much less easy and we will see that a slightly more practical solution exists.

PGP Encryption With Kleopatra

OpenPGP is a non-proprietary data encryption and authentication format based on public key cryptography. The latter differs radically from symmetric cryptography in terms of its handling. So, instead of using the same secret key to encrypt and decrypt data, two keys are needed here, one public and the other private. The public key can be known to everyone, because once it has been used to encrypt information, it is not sufficient to restore it. Decryption can only be done by the holder of the private key.

We can then advantageously use this property to protect sensitive data even before storing it in the password manager. First of all, by using a different encryption protocol, this protects us from any breach in the security of the manager itself. Then, we will be able to encrypt each new information individually and this operation can possibly be carried out on any computer; using the public key does not require any special precautions. The only truly critical operation comes down to the decryption of a piece of data using the private key, which must imperatively be carried out on a Tails session to be perfectly certain that it remains confidential.

Concretely, public key cryptography is used with the help of certificates containing, among other things, the famous pairs of public and private keys. Since the private key must be kept secret, it is not stored as is in the certificate. Instead, it is encrypted with symmetric encryption whose key, called a pass phrase, is chosen when creating the certificate. The certificate can then be used directly to encrypt any data, but the knowledge of the pass phrase is essential to further decrypt it.

The free software Kleopatra, available under Linux as on Windows, allows to create and manage such certificates, as well as to carry out the operations of encryption decryption. The first step is to create a certificate dedicated to the protection of sensitive data and that we save in the KeePass container. As explained above, a pass phrase has to be chosen for the protection of the private key. The easiest way is to use again the derivation mechanism we devised to generate the salt on the Yubikey. By applying it this time to the master key, we thus obtain a new code, easy to regenerate, which can be used as a pass phrase. Once the certificate has been created, it then remains to save it in the password manager to be sure not to lose it (without it, the encrypted data cannot be recovered).

All these different steps are illustrated in the red block on the drawing introduced above. Critical information can be seen passing into the PGP Encrypted block, the latter operating through a public and private key pair protected by a pass phrase generated from the master key. Once again, this mechanism provides strong passwords that can be easily recovered thanks the knowledge of a simpler root code.

Tails

As presented above, Tails allows you to run a reliable OS on any computer through a bootable USB key, used exclusively in read-only mode. This ensures that you always start a session in a trusted environment. Extremely well documented, usage of Tails shouldn’t be a problem for anyone, but it sure does require a bit of gymnastics and discipline. It is therefore best to reserve it only for the management of critical data which should not be accessed often.

For example, if you are managing your digital wallet recovery phrases on a computer, it is really a must that they never hit an untrusted PC in any way. The procedure to be scrupulously applied to save this kind of information is then as follows:

1. Copy your KeePass archive to a USB key;
2. Launch a Tails session on your PC;
3. Unlock the KeePass container on the USB key;
4. Extract the certificate dedicated to sensitive data and add it to Tails;
5. Record sensitive information in a text file or other;
6. Use Kleopatra to encrypt this file using the certificate;
7. Add the encrypted file to the KeePass container;

Then, before closing the Tails session and that the unencrypted sensitive information disappears, it is essential to verify that it is indeed possible to restore it using this same certificate and knowledge of the pass phrase.

Technically, adding such encrypted information to the password manager can also be done without going through a Tails session. The only thing that the latter provides is the assurance that the information to be protected cannot be stolen. It all depends a little on what we are talking about. Each case is unique and it is up to you to judge the incurred risk.

On the other hand, any decryption operation should only be performed in Tails, in order to be sure not to have the pass phrase stolen. Because if it gets disclosed, then all the data encrypted with the corresponding certificate gets compromised.

Backup Copies

Unlike many other password management solutions, KeePass software does not natively offer a mechanism to make backup copies of your data or to synchronize them across multiple devices. This functionality is, however, essential to be sure to never lose your passwords, even in the event of failure of your computer equipment.

Fortunately, and even if it is a little less practical, KeePass benefits from a wide range of optional plug-ins, some of which being dedicated to synchronization with the cloud. It is thus possible to synchronize its database with the usual file storage services such as Google Drive, One Drive, DropBox, etc.

The other option is to simply transfer your KeePass archive by hand to an online disk storage each time it is modified. But, whatever the chosen method, it is legitimate to ask the question of the security of such an approach: is it really acceptable to put your password database online and expose it to all dangers ?

The answer to this question is a big yes, and for several reasons. First of all, the container will not be directly exposed since it will be stored in some private space. And I’m sure that a place like Google Drive is better protected than your home PC can ever be. Then, even if a malicious person does manage to get their hands on your database, there is very little chance that they will be able to do anything with it. As long as a password container remains encrypted, it takes enormous computing power to break in. One small nuance, though, this is only true if you have chosen a strong password. Otherwise, I invite you to read this article to change your mind on the question. Finally, this password archive has been built in such a way that accessing the data it contains is not sufficient to directly access your various digital accounts ; because of the mechanisms we saw, like splitting a password in 2 pieces, or like the usage of double authentication or additional encryption. All of this put together makes it extremely unlikely that you could ever have anything stolen from you, at least numerically speaking.

Finally, it will be necessary to make a call on a friend to fully meet requirement 3, which states that all digital devices can be destroyed without consequence. If this does happen, you may no longer have access to the online file service where your password database is stored. It is possible to guard against this scenario by using any mailbox of an acquaintance to make a backup from time to time. Simply send a message with the KeePass container attached to and explain your recipient to not delete it. In addition, there is no need to spam your friends every time you make a change to your data, because the purpose of this email is simply to be able to access the online file service again.

Even if the security of an encrypted archive like the one created by KeePass is high, you might be reluctant to spread it widely and lose control over it. To be on the safe side, it is easy to encrypt the container before emailing it for backup. One option among others is to use Kleopatra which offers the possibility of performing symmetric encryption based on a password. The latter can be the pass phrase or another sequence derived from it. Then remove the extension of the file and give it a name that is not very explicit. No one else but you will be able to really know what it is about, and the contents of the file will be a simple block of random values revealing no clue.

Handover

If for some reason, it is necessary for someone to be able to access your password archive should the worst happen, you will need to store your root code, the secret derivation mechanism and clear instructions in a safe. Your legatee must also be one of the people to whom you sent the email containing a backup copy. From there, all you will have to do is figure out some way to give access to the safe to whoever you choose if the situation calls for it. The best way to get there is perhaps to go through a notary. In the meantime, your legatee will be unable to use the email you sent him and, on the other hand, someone who could break in the safe could not do anything with those instructions.

Conclusion

It is good to summarize ourselves after these long explanations. The various stages of this methodology are listed below and classified in different categories. Again, there are no unique ways to do this and everyone’s needs are different. So everything does not necessarily have to be kept and various steps can be adapted. The important thing is to consider all the worst scenarios and to prepare for them by having an appropriate response for each of them. To borrow a quote from Game of Thrones: “* What we don’t know is what usually gets us killed.*”

Standard set up

1. Get a Yubikey and a USB stick on which you flash Tails.
2. Install the KeePass and Kleopatra software. On Tails they are provided straight away.
3. Choose a root code and determine a secret derivation mechanism. This information should be remembered or put in the safe.
4. Derive salt from the root code and from the derivation procedure. Program your Yubikey to generate it when you perform a long press.
5. Create a new KeePass archive whose master key is given by: root code + salt.
6. (Optionally), install a plug-in allowing the synchronization of the archive with an online file service.
7. (Optionally), engrave the root code and the derivation procedure, then place them in a safe. Don’t forget to provide some instructions for the person for whom this information is intended.

Advanced set up

1. Transfer your KeePass archive to a Tails session using a USB key.
2. Generate the pass phrase using the master key and the derivation procedure.
3. Use Kleopatra to create an encryption certificate. The private key must be protected by the pass phrase.
4. Open the KeePass archive and add this certificate to it.
5. Bring back the KeePass archive with the USB key.

Adding a Standard Password

1. Ask yourself the right questions to find out if this password will include salt for added protection. The Yubikey key will then be needed.
2. Ask yourself the right questions to know if this password will be random and impossible to remember without the manager, or if you will be using a mnemonic to be able to use it frequently.
3. Add the password to your archive. If the password is random, let KeePass generate it for you.
4. If this is an online account, enable two-factor authentication. The ideal is the Yubikey, Google Authenticator (or similar) duo. The first one for normal use, the second one in case of loss of the key. The Google Authenticator seed must also be saved in the KeePass archive and be treated as a critical password.
5. (Optionally) if the Yubikey is enabled for two-factor authentication, remove this account from the Google Authenticator application.

Adding a Critical Password

1. (Optionally), transfer your KeePass archive to a Tails session using a USB key.
2. Open the archive and extract the encryption certificate to make it usable by Kleopatra.
3. Use Kleopatra to encrypt the information with the certificate.
4. (Optionally) and on Tails only, perform a test to verify that you can decipher the information using the pass phrase.
5. Add the encrypted information to your archive.
6. (Optionally), retrieve the KeePass archive with the USB key.

The decision whether or not to switch to Tails for adding such a password really depends on what is at stake. Many situations can afford to do without it.

Extracting a Critical Password

1. Transfer your KeePass archive to a Tails session using a USB key.
2. Open the archive and extract the encryption certificate to make it usable by Kleopatra.
3. Extract the information to be decrypted from the archive.
4. Generate the pass phrase using the master key and the derivation procedure.
5. Decipher the information with Kleopatra and the pass phrase.

Restoration in the event of loss of some equipment

• If you no longer have access to your KeePass archive, ask your acquaintances to resend your recovery email. Decrypt the attachment, open the archive it contains, and get access back to your online file service where the last fresh version of the archive is stored.
• If you have lost your phone and the double authentication it contained, recover them by extracting the seeds saved in the KeePass archive. This will enable to restore the two-factor authentication to the new phone.
• If you have lost your Yubikey, you will need to delete it from each account that uses it as a means of two-factor authentication. To do this, make sure you have your fallback authentication available on your Google Authenticator. Then connect to each of the impacted accounts to remove the access using the lost Yubikey, and replace it thanks to a new key. For added security, you may also need to change the salt used in the master key and in any other password using this technique. Concretely, this involves changing the root code and recreating new passwords using the derivation procedure. It all depends on the circumstances of the loss of the key and the risk that someone can try to use it against you.