Passwords and entropy

A password is a secret of which the knowledge gives a privilege.  The original meaning of '"password" was as follows: he or she who could say the password, was allowed to pass the guardians and enter the town or the castle.  It was a (secret) word or phrase that allowed you to pass.  In the context of cyber security, the privilege is not to be allowed, physically, to pass a gate or a guardian, but rather to pass an obstacle in order to:

  1. access information (read e-mails for instance)
  2. give instructions to a machine
  3. access a cloud account
  4. change the data in a machine

One can suppose that these privileges to do so have been granted for legitimate reasons.  In other words, you know the password, because you have a legitimate reason to read e-mails.  The password is only a short-cut to be able to automate your access, without having to verify in detail, again, whether you are the person that has legitimate access.   As such, even though the real goal is to give access to people having legitimate reasons to have access, one replaces this with a proxy: those people that can produce the password.  Ideally, the people, and only the people, having legitimate access rights, should be able to produce the password.  Is it possible that people that do not have legitimate access rights (which we will hence call "attackers") can nevertheless know, and produce, the password ?  There are 3 ways in which an attacker can produce the right password:

  1. a person knowing legitimately the password, has voluntarily given the password to the attacker
  2. a person, knowing legitimately the password, has registered the password somewhere and the attacker got a hold of that registration
  3. the attacker guessed the password

 It is clear that the nature of the password doesn't play a role in the first two cases ; however, it is primordial in the third way of doing.  Here again, we have to distinguish two cases:

  1. in trying to guess the password, the attacker has a way to verify whether his guess is the right one
  2. in trying to guess the password, the only thing the attacker can do is to use his guess, and hence, betray the fact that he's guessing

The most dangerous case is the first one, and it is there that we have to introduce the important notion of entropy of a password, which is an objective measure of the difficulty of guessing it.

An often committed error is to think that if the way we got to our password is essentially impenetrable, then the attacker can never guess it, because he cannot follow the same reasoning. Let us imagine that I have to pick a password consisting of a single digit.  This digit, I obtained it in the following way: I take the day of the month of the birthday of my wife, and I multiply it with my year of birth.  I add the square of my house number to this, and I multiply everything with the 3 last digits of my credit card.  I subtract from this the four first digits of the phone number of my aunt.  Of the result hence obtained, I take the second digit: that's my password.  It turns out to be 8.  Nobody can guess that, right ?  Nobody knows how I obtained this number, let alone, knows the data, like the phone number of my aunt.  Well, the point is that an attacker doesn't care: he only has to guess one digit, and hence, simply has to try: 0, 1, 2, 3, 4, 5, 6, 7, 8 or 9.  If he can try 10 passwords, he'll know for sure what is the password, without ever knowing how I got there.  And he'll get illigetimate access.  The reason why this was simple, was that there were only 10 different passwords possible.  How we got there doesn't matter.  One says that a single digit is a password with a very low entropy.  The entropy is essentially the logarithm, in base 2, of the number of different possible passwords, and is expressed in "bits".  Here, the "digit of pass" has an entropy of somewhat more than 3 bits (3.32 bits to be more precise).  It is a very small number.

A good password has a lot of entropy.  There have to be a lot of different possible passwords.  And at the same time, one has to remember the password, because if one doesn't, one is going to write it down on a post-it, and the password will become vulnerable to another attack.

Entropy is additive, in the following sense: if one combines two passwords into one single one by concatenating the two strings, the entropy of the combined password is the sum of the entropies of each password individually, on the condition that the choice of the two pieces was independent.  As such, a password consisting of 3 digits has an entropy of three times 3.32, which gives us 10 bits.  One has indeed to guess about 1000 times from 000 to 999, to be sure to find the right one.

There are more letters than there are digits: there are 26 upper case letters, and 26 lower case letters.  That's 5.7 bits.  A password consisting of 3 mixed upper and lower case letters has hence 17.1 bits of entropy.  That's still small, but it is more than the entropy of a pin code of 3 digits.

A random word in an English dictionary has about 10 to 12 bits of entropy (depending on whether the dictionary contains 1000 or 4000 words).  However, one better considers 7 to 8 bits per word if the word is part of a phrase, because there are correlations between the words in phrases (random words don't make up a phrase).  Some research indicates that the entropy of a spoken language corresponds to 6 - 11 bits of entropy, depending on the discourse and the language.  A rough estimate of 7 or 8 bits is hence a good indicator, without any pretension of precision.

If one can combine digits, letters and special symbols like +,-,#,$,% etc... one can obtain almost 7 bits per symbol.  This is the reason why many advices concerning passwords tell you or even oblige you to make a password that contains letters in upper and lower case, digits and special characters, in order to increase the entropy per character.  This is entirely stupid.  The only reason why this did matter in the past, was that passwords were made up of a very limited number of symbols.  20 years ago, UNIX accounts had 8 character passwords, so to cram sufficient entropy in only 8 characters, one needed to have as much entropy per character as possible.

Making up such passwords is stupid, because it is very hard for a human being to remember such a string of random characters without meaning, which will imply that one will use short passwords if one has to use these funny things.  What matters is not the entropy per symbol, but the total password entropy.  Rather have a very long password with very high entropy, but with relatively low entropy per symbol, than a short password with low entropy, but high entropy per symbol.

The password "the_day_I_met_my_wife_I_was_in_fact_on_the_Eiffel_tower" contains much, much more entropy than "Ux%!4Fk7" and the first one is much, much easier to remember than the second one.

The first password has about 14 x 8 = 112 bits (or 14 x 7 = 98 bits) of entropy, while the second one has 8 x 7 = 56 bits of entropy.  The first password starts to have an amount of entropy comparable to a cryptographic key ; the second one is a good password, but a weak key.  But the most important is: the first password is much easier to remember than the second one !  In order to have the same amount of entropy, one would need about 16 characters of weird symbols:  "Ux%!4Fk78C*)Bz;v".  Go and remember that !

One still finds a lot of suggestions to make passwords with bizarre characters and random choices, but one cannot remember them.  I would urge you to pick an unusual phrase that you will be able to remember, containing several words, that doesn't come from a book, a film or a song lyric, but that you invented yourself.  If you can put in there, in a natural way, words from different languages or self-invented words, that's all the better.  Connect the words with a symbol of your choice, but make it such that you'll be able to remember it easily.  You'll get a password with an entropy of about 8 bits per word.  If you have 5 words in your phrase, that'll be a 40 bit entropy password, grossly.  If you have 10 words, it'll be 80 bits.

What's the use of all this entropy ?  It indicates the number of trials with an answer that are needed on average to guess the password without any other information.  This amount of trials will indicate whether guessing the password is practically feasible, how much effort it will cost, and how long it might take to do so.  The guessing of the password shouldn't be feasible for the probable attackers.

But what is a trial ?  One needs to distinguish whether one can try off line, or whether one needs to actually use the password to see whether it is right in a true communication.  If one needs to try with a true communication to convince a reliable machine, then a few tens of bits of entropy are largely sufficient.  The PIN code of your credit card contains only 4 digits in some cases ; that's only 13 bits of entropy.  This is very weak, but the only way to guess it, is to try it with the physical credit card in a teller machine ; after 3 failed trials, the card is blocked.  This means that one needs to steal, on average, 3300 credit cards in order to guess one right code before it gets blocked ; in that case, you will be able to abuse the card until the legitimate owner blocks it.   If you have the unlimited right to try one password per second, then a 20 bit entropy password will be guessed in 12 days (but you will see it, because during those 12 days, one will have someone trying and failing every second.  A password of 30 bits will take 34 years to be guessed that way.  A 10 bit password will be guessed in 20 minutes.

We see the implications on the security immediately: guessed in 20 minutes (10 bits - one word) ; guessed in 12 days (20 bits - 2 words) ; guessed in 34 years (30 bits - 4 words).  A password of 30 bits is hence totally secure in this case, and a password of 10 bits doesn't mean anything.  A password of 20 bits can be secure if the system administrator is vigilant as to repeated trials over days.

As such, if a password is used in a system that implies a "true trial" to find out whether it is right or not, and if one can put in a dead time of 1 second on the trial (that doesn't penalise the legitimate user), we see that passwords of 20 bits or more are OK.  One could of course block the account after a number of failed trials, but that would open up the account to a denial of service attack: by trying randomly, one could lock out the legitimate user that way.

On the other hand, if the attacker has elements that allow him to test off-line whether the password is right or not, then with the current state of technology, we have that:

  • a password of 60 bits of entropy will be broken by a modest but determined attacker
  • a password of 80 bits can be cracked by an attacker with significant means (spy agency, large financial group...)
  • a password of 100 or more bits is out of reach

We see how important it is to try to avoid that passwords can be checked off-line.  For instance, if a file is protected by a password, and the file is stolen, can the thief verify, with just the file, whether the password is right or not ?  With dedicated means of less than $10.000,-, one can test a password every 10 microseconds or faster ; a 20 bits password is guessed in 10 seconds ; a 30 bits password is guessed in 3 hours in the best case.

Password versus key

The distinction between a password and a key is that a password is supposed to be learned by heart and typed on a keyboard by a human ; a key is registered on a device (a computer, a smart phone).  A password, as we've seen, doesn't have much entropy, and it is not reasonable to ask a human being to know a lot of passwords.  A key, on the other hand, can contain a lot of entropy, but a human being cannot remember them.

The security policy we propose consists in transforming most of the passwords into keys.  One can effectively consider that a lot of applications are still on the mode "password" to give access to their users.  This is not the smartest way to authenticate, but one doesn't have the choice in many cases.  Most of the cloud services, for instance, have only a password authentication mode.  If you want to connect to your Facebook account, you need a password for your account.  If you want to connect to your Twitter account, you need a password.  You'll need a password for most of your forum accounts.  If you want to buy stuff on Amazon, you need a password to your account.  If you want to read your e-mail, you'll need to access the server with a password.

It is simply not reasonable to have large entropy passwords known by heart and different for all these applications.  Hence, one uses one of these three failing "strategies" :

  1. One makes up one good password, once and for all, and uses it everywhere (eventually with small variations)
  2. One uses a lot of different simple passwords
  3. Worse: one uses a single, simple password everywhere

This is perfectly normal and not the human's fault: it is the fault of the fact that a lot of services do authentication with a password, which is a bad way of doing.

The best solution, when one is forced to use a password for an application, is to consider that this password is simply a key.  One doesn't need to remember the key, but it has to be registered safely somewhere.  In principle, keys never have to be learned by heart, and never or rarely have to be typed in manually.  But this is where things can go wrong: most applications requiring a password present a human interface where the human is supposed to type in his password.  So one needs a mechanism that can do this automatically, but one needs to realize that this is a plaster on a bad technology, imposed by many badly conceived applications.

A password that became a key has to be generated randomly, and can contain as much as 6-7 bits per character if one can put in there upper and lower case letters, digits and special symbols.  There is no reason not to use the maximum allowed number of characters (because on top of that, most services limit the number of characters in the "password").  Such a key/password will contain 120 - 140 bits of entropy if it has 20 characters: this is perfectly safe.  If one can use 30 or 40 characters, why not, it is even better, but usually the auxiliary security isn't that safe, so it doesn't bring in much more - but it doesn't cost much more either.

In conclusion: generate key/passwords in a random way with upper and lower case letters, digits and eventually special characters, use the maximum number of characters allowed, or at least 20 characters, and you're safe.

But now, this key/password has to be registered somewhere.  This is where one needs to use a password manager, to adapt to the fact that it is a key, but by error considered as a human-typed password.  The password manager is hence a kind of equivalent to the key ring of most operating systems, but with the possibility of easily copying and pasting the password in human interfaces.  If it weren't for this, the system key ring would be sufficient.

The fundamental problem is now this: everything is done for the "password" to be typed in by a human, even though in reality it is a registered key on a machine.  How to get these keys to other machines without compromising them ?  A true password doesn't have this problem, because it travels with the human remembering it, but a key is registered on a specific machine.

Local password

A true password does remain a very important and useful security mechanism, but as it is a fragile secret with not much entropy in most cases, and which has its full value only when it is memorised, and its most evident form is a long phrase, one has to:

  • limit the number of passwords to remember
  • limit the number of times one has to type it in during normal use

Let us consider some different strategies and let us think about eventual inconsistencies in the ways of doing:

The first case consists in picking a single good password of about 30-40 bits of entropy (4 - 6 words) per environment, and that's it.  One uses this password to log in.  One could eventually use biometry too.  The key/passwords are in the clear on the machine, but in files that are only readable to the user.  This corresponds to a personal machine where one is the sole administrator, and where the physical access is entirely under control (one doesn't fear any intrusion or theft).  The password only serves to avoid eventual intrusion by relatives or colleagues.  The advantage is that this is a very light system, but the price is that the protection is minimal.  Nevertheless, this becomes already a much better protected system if one uses full disk encryption (with the given password).  A 30-40 bits password will not stop a thief from breaking the password (30 bits is a matter of minutes or hours, 40 bits starts to play in weeks), but it protects against occasional intrusion, and it renders, nevertheless, the task much harder for an attacker.  An encrypted disk protects against the attack "quickly boot the machine on an external system and copy some files".

The second case looks a lot like the first one, but this time, we are going to encrypt the keys/passwords with the same 30-40 bits entropy password you used to log on.  This use case, which may seem strange, has an advantage: your keys/passwords are protected somewhat against an administrator of your machine.  In fact, this technique protects your key/passwords as well as full disk encryption.  It also protects against the occasional intrusion by a colleague, even a system administrator.  The protection is light: those who can access the encrypted file can, with sustained effort, crack the password, but it nevertheless makes the task harder.

It doesn't serve any security purpose to encrypt the key/passwords with another password than the log on password of similar entropy.  Effectively, in as much as you can fear that your access password is compromised, an attacker can always install a key grabber on your system that will spy on your other password.  If your access is compromised, in any case, nothing is safe any more.  So in as much as your log on password is not compromised and considered secure, you can use it to protect your key/passwords too, and in as much as it isn't safe, you cannot protect your key/passwords any more in any case.

One could use a password with large entropy (>80 bits) to connect and/or encrypt the local key/passwords.  This has a meaning when your machine is physically less secure: a portable computer for instance, or something with strategic importance.  But the price to pay is that you will have to type long passwords each time you use them.  Using a weak password to log on, and a strong password to protect the keys, is useless, for the same reason as said before: if one has access, one can spy on you typing the strong password.  If you take the pain to use a strong password for the keys, use it also to log on and use full disk encryption.

As such, we have locally, 3 reasonable use cases, depending on the situation:

  1. no password, or password only to log on, keys/passwords in the clear, on a physically secure machine
  2. password to log on, full disk encryption, but once logged on, keys/passwords in the clear
  3. password to log on, and same password for key/password encryption (one can use, or not, full disk encryption)

In the first case, the security of your keys comes entirely from the physical protection of the machine.  If you are absolutely sure that the machine cannot be accessed physically and that it cannot be compromised, there's no reason to protect it with a password.  For the two other cases, the strength of the password (30 bits - 80 bits) depends on the estimated threat, what is at stake, and the pain of typing long passwords.  The longer the password, the better it protects, but the more it is a pain to have to type it each time.  A short password protects against occasional intrusion ; a long password buys you time to change all keys in case your device is stolen.

The password managers in Firefox and Thunderbird do an excellent job for what we are talking about here.  Just activate "master password".

Keep your human capacity to remember different passwords rather for different environments (private use, professional environment, sports club ....).

One has to realize that even a "weak" password, when the keys/passwords are only kept locally, can give adequate protection if the password protects sufficiently against the local intrusion, and if you don't fear any local intrusion, you don't even need a password.  In that case, your security only depends on the entropy of your externally used keys/passwords and not at all on your eventual real password.

Cloud password

Things are entirely different when one keeps one's keys/passwords in the cloud, because then, you've given up the local protection and the password is the only remaining protection against putting your keys/passwords in the hands of everyone on the internet.  So it is simple: if possible, don't put keys/passwords in the cloud.

I think one should avoid the use of any cloud-based password manager if one can do otherwise, and if ever one has to use it, one shouldn't use a true password, but a key, so one should use it in an indirect way.  Effectively, the standard usage of these tools (like Lastpass, Firefox Sync. ...) is dangerous, because one exposes all one's high-entropy keys/passwords to the entire internet, only protected by a lower-entropy true password.  Indeed, everyone who can access the account of the password manager (so, by guessing the lower-entropy password) has access to all your keys.  Your keys are encrypted in the cloud, but only with a password, not with a true key and that's all you can ever control.  Of course, if the manager works correctly, he'll put a dead time on trials and so on, but you don't control that.  Apple's Icloud, in 2014, had a bug that allowed people to try many passwords without dead time, which gave rise to a celebrity pictures leak.

It is a total aberration to protect several high-entropy keys with a lower-entropy password.  The only reasonable way to put a list of keys in the cloud, is to encrypt it with another key of at least similar entropy.  The only credible way to use a cloud password manager is by using a key for that manager, which pushes the problem to the management of that key, but it is true that there are less keys to manage.

There are of course two standard applications that use regularly "passwords": your internet browser and your e-mail client.  I seriously propose to use Firefox and Thunderbird respectively for these two functions.  These two applications have a good local integrated password manager.  If one activates the "Master Password", one has the keys/passwords encrypted by that password, and this, locally.  However, the use of the Master Password can be a (slight) nuisance because one has to type it once a session at least, but this is exactly the trade-off that was discussed before.

There is only one single good reason to use a genuine password (one that you remember) in the cloud: when you are obliged, or think you may be obliged, to travel "naked", without device.   For instance, you are fleeing (or you may consider the possible necessity of fleeing in the near future).  Or you are living in an environment that can be destroyed, or from where you can be excluded at any moment.  In that case, one has to learn by heart a password that has at least 100 bits of entropy, and you can use it directly in the cloud.  But you should only consider it in this case ; and you still don't need a dedicated cloud password manager, but only some storage in the cloud.

One has to realize the huge difference between keeping one's keys locally, or keeping one's keys in the cloud.  Local keys have only to be protected against local intrusion: relatives or colleagues or occasional visitors ; the worst case is theft, which can happen, but of which one can hope that it doesn't happen unnoticed.  The protections then only need to last the time you need to change all the keys, before a thief cracks your vault.  Most of the thieves of hardware are actually not interested in cracking passwords, but rather sell the hardware - however, this is part of the threat analysis.  In any case, the attack surface of locally kept keys is rather small in general.

On the other hand, keys in the cloud can be attacked by anyone, and you won't know it.   The attack surface is large, and you don't know it

One can object that the local attack surface also contains the compromising of the machine at hand.  This is true, but against a compromised machine, no system exists that can protect keys, because all user interaction, and all files on the system are then compromised, whether the keys come from the cloud or from a local vault.  If one accepts to handle live keys on a compromised machine, then there's no use in trying to protect them.

As such, the only relatively safe way of having keys in the cloud, is by encrypting them with other keys that are not in the cloud, or with an exceptionally good password, with more than 100 bits of entropy.  Of course, the encryption and decryption have to be done locally in any case.

The golden rule is hence: anything that leaves the local environment (anything "cloud") has to be protected by keys (not memorised) which are unique.  Passwords are only used locally.  The only exception is the naked trip.

This leads us to the problem of synchronisation of the knowledge of the keys on different machines.


The real password doesn't have any synchronisation problem, because it is in the head of the sole entity that has to know it: you !  As password systems have been designed with that in mind, there has not been any provision for synchronisation for key/passwords.  As such, there are proposals to use cloud-based password managers that will do that for you, but we just argued against that position, because you lower the security of your keys to that of a password as sole defence against the whole internet.

If you only use one single machine, then the problem doesn't exist.  You use the local password managers of Firefox and Thunderbird (and Filezilla) and that's it: your keys are present in those applications on your machine, don't leave it (except for a back-up, see further).  But most of us use several devices (portable computers, desktops, smart phones, tablets...).  It would be great if one could have access to one's keys on all these machines.  How do we do so ?

I propose to use a local and dedicated password manager.  In fact, I only know one that satisfies all requirements, even though it is not the most user-friendly: it is Keepass.  I think a good password manager should at least satisfy these requirements:

  1. open source (to make sure that it isn't stealing all your credentials and doesn't contain a back door)
  2. be local, without an account in the cloud, and working off-line
  3. have some functions like a good random password generator
  4. be multi-platform, so that one can use it on different kinds of devices under Windows, Linux, Android, Apple....

Keepass is in fact only a manager of a small, encrypted database, with some utilities on top of it such as a random password generator.  Moreover, the encryption of the database has an incredibly useful feature: it can be encrypted both with a local key (on a file) and a password.  This will be the tool we'll use to synchronise "in the cloud.

I would advice not to use the add-ons to use Keepass automatically in Firefox.  Use Keepass as a separate tool, in which one fetches the keys/passwords to copy them into Firefox, Thunderbird and other applications, when one needs them the first time, and use the local Firefox, Thunderbird and other password managers afterwards.

Keepass associates a password to a vault (an encrypted database).  This password will be the same for all usage.  As such, one needs a vault per environment, even though you use keys in two environments.  The vault belonging to an environment should be encrypted with the password of the environment (as well as the Master passwords of Firefox and Thunderbird), if we are to keep the policy of a single password per environment.

There are different ways in which one can use Keepass, depending on the needs:

  1. share a vault on a safe local network (there's a "master" vault on a local server, and one copies a local copy of it on a machine, to copy it back to the master if one has added keys to it)
  2. share a vault on a local network, and use a local key on your machines
  3. share a vault in the cloud, and use a local key on your machines
  4. share a vault in the cloud, and keep your local key on a memory stick
  5. keep your vault on a memory stick

If you use a vault with only a password (so, without a key), everybody who can have a copy of the vault and can know or guess the password will access all the keys inside.  If your local network is secure, you can put your vault on a local file server, and you can use it from any machine on that network.  It can be a good idea to make a local copy of the vault, for instance, on a portable computer that can be disconnected from the network, so that you still have your vault with you if you travel.  This is the typical use case when you are on a trusted network and you don't know in advance on which machine of the network you might need your keys.  This is the case when you have a small company network, and one adds often machines where anybody works on about any machine.  It can also be the case for a small domestic network.  There's no point in having the encryption key on all machines, because then that key doesn't protect anything: there were a vault can be stolen, the key can be stolen too.

If you need more security, you can use the double encryption feature of Keepass, using a key.  As such, one needs to copy (once) the encryption key on all machines where you want to use a vault.  As such, one can exclude certain machines of the network from being able to use the vault (even if they know or guess the password).  One has, of course, to transport the encryption key from one machine to another using a different pathway (don't leave the key on the network !).  One can use a memory stick for that, or one can use encrypted e-mail to do so.  From the moment that the machines where you may need your vault are limited in number and don't change too often, that's a good way of doing.

Exactly the same technique can be used in the cloud: you put your vault in the cloud (Dropbox, Megasync...), but you distribute the encryption key "by hand" or by encrypted e-mail, on the machines where you need to use the vault.  However, if you don't really need to put your vault in the cloud, it is nevertheless better.  In any case, never put your encryption key in the cloud, except, as we said, by encrypted e-mail.

Finally, another option is that you walk around with your memory stick containing your vault.

If you have keys/passwords to synchronize over several devices, you have to update the vault locally, but you also need to update the master vault.  It can be a good idea to combine Keepass and Git.  This helps you to use the synchronisation mechanisms of git for the Keepass vaults.  Of course you can also copy the vault by hand, but that has the danger of over-writing the vault with a bad copy.  So we suppose that you have one or another way to have synchronized vaults on different apparatus.  How do you use it then ?

If you use Thunderbird and Firefox, and you need to access for the first time on that machine, an e-mail server or a site with an account, but of which the key is already existing and contained in your vault, use Thunderbird or Firefox normally, and when it asks for a password, you open the Keepass vault, and you copy the password into Firefox or Thunderbird.  Next, you register that key into Firefox or Thunderbird's password manager.  The next time you need that password on that machine the local managers know the password already.

If you create a new account and you have to decide for a new password, you open Keepass, you add a new entry to the vault.  In Keepass, there's a good password generator, where you specify the type of password (number of characters, whether it contains upper and lower case letters, digits, special characters....).  Next, you handle like before: you copy the password from this new entry in the vault, into the application where one is asking for you to define a new password.  One shouldn't forget to update the master vault again.

If a new password is given to you (you don't have the choice), then you can add a new entry into Keepass, and you copy the given password into it.  Here too, one will need to synchronize the master vault.  For Firefox and Thunderbird, this comes down to a new password to be learned and stored in their local vaults.

If in general, you don't create many new passwords a day, the outlined technique is largely sufficient and safe: you use Keepass as a synchronisation mechanism, and you keep, for daily usage, the keys in Firefox's local password manager.  In that case, you could consider using Mozilla Sync to synchronize your Firefox kept passwords ; only, you should use a Keepass generated key for the Sync account, distribute that key with Keepass, and then use this on all machines to synchronize the Firefox passwords through Mozilla Sync.  Nevertheless, Mozilla Sync is a cloud based key manager with the potential vulnerabilities that come with it, so only use this option if it is really necessary (and only with a key, not with a true password).

Back up

We've been talking a lot about passwords being stolen or guessed, but the inverse problem is also important: loosing your passwords or keys !  A lost key is lost forever.  One needs to protect them against theft.  With the vaults of Keepass, which are simply files on your machine(s), however, there's no danger of loosing them, because they take part in the normal back up process of the machine(s).  There is a back up of the machine, right ?!

The only thing that could happen, is to forget a true password.  You can have a health problem that makes that your memory doesn't work well any more.  So write the passwords you really need somewhere on paper, and lock that paper up in a real safe, or deposit it with a notary or something.  Do this with all important passwords that are not in vaults, especially those that unlock crypto money wallets.  The day that you die, or the day that you've lost your cognitive means, your relatives can access to your digital assets.   This is true for the personal side of things, but something similar may apply to the enterprise environment.  In as much as your keys are for professional usage, it can be a good idea to have the possibility to access, in a controlled way, the key vault of a colleague that isn't available.  The company owner or CEO may keep a vault of employee passwords for their professional vaults.  One can work out a rather secure scheme where as a last resort, one can access the professional passwords of colleagues that are not reachable.

Policy of changing passwords

Contrary to what is usually thought, there is no need to change regularly passwords and keys.  The only reason to do so is when there's a hint that a password or key is compromised, and then one has to act quickly.  It is relatively rare that compromised passwords are not used right away.  A password of large entropy that hasn't been compromised, doesn't need to be changed, and a compromised password needs to be changed immediately.  Changing a password every 6 months has no meaning.  The difficulty in changing true passwords regularly is that one is not going to remember so many passwords and one will start inventing "systems" that render, finally, the entropy of the passwords much lower than if one would have kept a good password for a long time.   The problem of changing keys everywhere, every 6 months, is that it is a pain and that the procedure of changing them itself is vulnerable.  However, from the moment that one has the slightest hint that a specific key or password may be compromised, one should not hesitate to change it.  As long, however, as there's no such hint, it is better to keep things as they are.

Beware of "password recuperation" features

A lot of services in the cloud offer the possibility to "reset" the password if you forgot it.  Often, this happens by sending you an e-mail with a link in it that allows you to reset your password to something else.  This link contains, in fact, a code, an "intermediate password" that allows the person knowing it, to change the password of an account.  When you think about it, that kills entirely the very protection a password is offering !  An attacker now simply has to get a hold of that e-mail instead of having to break a high-entropy key !  The true security of the account is then whichever is lower in safety: access to that e-mail, or guessing the password.

As most often, such a feature cannot be disabled, the ultimate security of a cloud service is linked to the security of an e-mail account.  The security of an e-mail account doesn't only concern the contents of the messages in there (which may be considered not to be of a high importance) but also the security of all cloud accounts that use this e-mail address for a recuperation of password.  This is why it is important to protect an e-mail account with a high-entropy key, to use a reliable e-mail provider, and, most importantly, to use only encrypted links to your e-mail provider (TLS/SSL).  That said, because your e-mail is in the cloud, with a provider, you don't have, most of the time, any control over it, unless you set up your own e-mail server at your place (which is a possibility to consider).

Some password reset mechanisms send the reset link to your phone with an SMS: in that case, the security is linked to how well you protect your SIM card.  Anybody having access to your SIM card can then get that link and reset your password.

Facebook has a very good solution to this problem and this potential danger: if you give a public PGP key to your Facebook account, you can configure it so that it sends you the reset link in an encrypted e-mail.  As such, an attacker that has access to your e-mail server won't be able to read the link.

One has to be very wary of "confidence questions" such as "the maiden name of your mother" or something of the kind.  In as much as they are a supplementary protection (a thing you have to answer together with giving your key/password) there's no worry.  But in as much as they offer a parallel access, or a right to change the password, one needs to consider these answers as passwords themselves, and one needs to provide high-entropy "answers" to them.

The security of any cloud account is not higher than the weakest method of password recuperation or reset.  If you manage well your keys, you will never need these methods ; so you only have to make sure that they don't become a security hole.  If you can disable them, do so.