Secure and Easy Password and MFA Management
2023-11-23: Google Authenticator (GAuth) now syncs data with the cloud, allowing its users to recover MFA data if they get their devices lost. This completely changes the approch showed here to handle GAuth backups, but it also poses a vulnerability since each factor of the MFA should be independent from each other (what you have, the GAuth data is being secured by what you know, your Google Passwords).
Keeping credentials secure is key for good security architecture, but since there are lots of technologies to help users achieving that, most people do not know how to correctly use them. In this text, I am going to expose my way of managing passwords and Multi-factor Authentication (MFA) tools to keep my access both secure and easy to use, while maintaining a certain level of resilience in case of losing a key device or password.
Passwords
The most basic level of authentication is the tuple username and password (something you know), but although it always worked, it is impossible for a human being to use passwords securely without support tools. A secure password must:
- not repeat between services
- not be a part of a dictionary (although an unusual combination of words are OK)
- be composed of many charsets (
numb3r5
,letters
,LETTERS
,$peç!a!$
)
This way, making use of a password manager (PM) is paramount to securely use passwords in the 21st century. A PM (I recommend Bitwarden) will not only keep track of every password, but usually, they still can generate secure random passwords, so the user can use them to sign into applications. In this scenario, the password generator pattern is important: all passwords must be randomly generated and stored in the PM and the pattern must be the more secure the application allows. Take this as a baseline:
- 40+ characters
- Uppercase letters
- Lowercase letters
- Numbers
- Special characters
- Never reuse passwords between applications
Since the passwords are randomly generated, they are not usually susceptible to dictionary attacks.
While using a PM is a good idea, keeping a secure backup of the passwords database is essential if the PM is unaccessible, but this backup must be cryptographically secure and the user must not depend on the PM itself to recover the PM's backup decryption password. Still, users will have to create and remember two passwords:
- PM's
- PM's backup
The best practice here is to think in a passphrase, add numbers and special characters, and make sure the final result is easy to remember. Although the passwords should be easy to remember, the users should not trust in their memories, so they should write down both passwords on a piece of paper and keep it in a secure, yet easy to access place.
Use absurd thoughts and characters combinations to create secure passphrases, like K1d_M@mb0_Jung!3
, B3st**!n**Pe4ce
, and H4ir%oh%da%D0g
.
Since everyone has many accounts with passwords spread over the internet, none of them tracked by a PM, to start using a PM, they should first create an account and harden the access to the PM using a secure password and enabling MFA. Only after that, they should start storing their credentials in the PM. The best PMs offer tools to analyze what passwords are weak and what passwords repeat across accounts. The user should start changing those passwords for the (random) ones the PM generates.
MFA
MFA should be enabled for every critical service to provide a better level of security. In a perfect world, all accounts would have the MFA enabled, but this requires a lot of effort and since the PM is generating and managing secure passwords (strong and unrepeated), the risk is mitigated for non-critical services.
In this scheme, the PM is a critical service and the cloud storage where the PM's backup is kept is also critical, so both of them should have the MFA enabled.
MFA can be achieved in some ways, for instance:
- using a TOTP generated by an application
- sending SMS to a pre-defined telephone number
- receiving a phone call with the OTP
- sending email to a pre-defined address
Enabling more than one alternative of OTP is good practice here, so the risk of losing an account is reduced, but users must remember that this also elevates the criticality of a given service. For instance, if an email address is set to receive OTPs, the access to this email should be hardened, although using MFA here could be disastrous.
A good application to manage TOTPs for MFA is Google Authenticator (GAuth), but in its current version it works "ad-hoc". In other words, it does not sync data or keep backups of any of the MFA codes in there. The only option GAuth gives to the users is to export data to another device, but if the user gets his cellphone lost or stolen, he will not able to do that. Fallback solutions must be in place to restore access to the service and they could include:
- another way of receiving the OTP (mentioned earlier in the text)
- using a recovery code
- backing up the OTP application
Recovery codes can be used only once, so after using one of the N codes provided, this code becomes invalid. Users must make sure of generating new codes before using all available codes.
There is no consense among services on how to provide a fallback solution to MFA. Some of them allow the users to see the private key for the TOTP, others allow users to take note of recovery codes, and others allow users of setting up other ways to receive the OTP. But if the user has none of these options, the only thing left is to back up the content of GAuth, which is not trivial.
Other solutions such as Microsoft Authenticator and Authy provide ways of backing up data, but I prefer GAuth.
To backup GAuth data, the user must trick the application like he wanted to export GAuth's data, but instead of reading the generated QR code with another GAuth instance, the user will take a photo of the cellphone's screen (GAuth blocks screenshots while showing the QR code). Needless to say, this must be done in a secure place and using trusted devices.
The photo must be kept secure like the PM's database backup, preferably using encryption in the process. To make sense, the MFA's backup password should be not kept in the PM because it has the potential to compromise the MFA security in its essence.
Backups
At this point, the user has two backups: the PM and the MFA's. But how to perform it in a secure and usable fashion? A few things should be considered:
- Frequency of backups
- Cryptographic automation
- Backup storage
- Password book
- Backup recovery testing
The majority of this process is manual (because in the real world users do not have a enough technology to create secure automation), so the user must set a kind of reminder to redo the backups, considering that password and MFA management are updated frequently. For the critical services, I would suggest that a new backup should take place right after any changes in the password or in the MFA.
To make it easier for me to keep the backups secure, I wrote the bookepr script to automate the packing and unpacking processes. It zips files or directories, encrypts the zip using AES-256 and GPG, and removes the original files. The password used to encrypt and decrypt is manually typed and managed by me.
After having the backup data, I move it to cloud storage keeping two copies, one local and the other remote. The backup password is kept in my "cold" password book, which I keep in a safe and accessible physical place for me (it must not be digitally stored). Then, periodically, I test the backup recovery to ensure that I will be able to restore all of my access credentials when needed.
Bottom Line
- Passwords are better managed with a PM, but users must grant the security of such tool.
- Every critical service must have MFA enabled, especially the PM and the cloud storage (backups).
- The "cold" book must be in a secure place, but easy to access and it should only contain the necessary passwords.
- The manually generated passwords must be secure and the PM's password generator should be configured to generate the strongest passwords each service supports.
- All accesses to the PM and backups must be done in trusted devices in trusted networks.
- No password repetition is allowed.
Last Words
Although passwords are used daily by many people for many decades, it is hard to keep them secure against the modern world's challenges and threats. Users should use specialized tools and technologies to harden the access security of the services they use or else they will be easy prey for threat agents.
Even knowing that there is no perfect security, the key is to mitigate the risk and rise the security to a level that makes the user uninteresting for threat agents. In other words: the evil guys will find it so hard to hack the user, they will give up and find another target.
Users also should notice that rising security levels could be disastrous if techniques such as MFA are enabled and rely only on one device or method.. That's because the loss of that device could lead the user to lose access to the service forever. Then it is important to understand how it works and how to properly configure it.
Finally, security is better applied in more than one level, so having good and manageable passwords and MFA is just the tip of the iceberg. Users must ensure to make them available using some sort of backup and remember to keep the security of every system where they use them. The "defense in-depth" concept fits well here and even social engineering attacks such as shoulder surfing must be considered to keep security.
Update 2021-11-01: Enabling Copy and Paste in Some Websites
For some unknown reason, some sites block copy and paste functions. For me, it's nonsense because password managers are reality and it is impossible to keep all passwords in mind in a secure fashion. Fortunately, this post shows some hacks to re-enable such functions. I tested the "paste hack" and it is very easy: in Chrome, open the console (option-command-j
) and paste there the snippet below. Pasting should be enabled right after pressing enter
.
var allowPaste = function(e){
e.stopImmediatePropagation();
return true;
};
document.addEventListener('paste', allowPaste, true);