work on mistakes
A complex system is not complicated, but simply described as such
In the previous article, I described my setup for storing autorotation data (passwords). Many experts have studied it and provided their comments on where the problems might be, what could be simplified, and what could be done differently.
But we’ll start with a little explanation of why the system is so complex. Let’s remember the essence:
1) To log in to “unimportant” sites (for example, into the account of another AI product), we use a unique password, which we store in a password storage program (password manager)
2) To log in to “more important resources” (for example, to an account on github), we use a unique password, which we store in the password manager, plus a one-time password (TOTP – Time-based One-Time Password) which will be shown to us by a special application on the phone .
That’s all. This is the whole point of everyday use of the entire system. But why did it seem so difficult then? Probably due to additional layers of protection from oneself or any unforeseen factors. Namely:
Protection against losing our phone. Creating and storing a copy of the application settings with one-time passwords so that you can configure it on a new phone.
Protect against your password manager stopping working. Creating and storing a copy of all passwords in a separate file.
Protection against forgetting the master password from the password manager. Create and store a printed copy of master passwords.
Since these precautions create a new security hole, we have to complicate the system and encrypt backups:
We encrypt a copy of the TOTP settings (with the password from the one-time password application)
We encrypt a copy of all passwords from the manager (with the password from the password manager)
We cut a copy of the passwords on a piece of paper into 3 parts according to Shamir’s scheme and hide them in different places.
We use it as a password manager Bitwarden.
As TOTP we use Aegis.
As a tool for dividing notes with passwords, we use Bananasplit.
We use as an encoder Picocrypt.
Why can’t you use 1 password everywhere?
Using one password everywhere is a very popular scheme. It is comfortable and natural. As soon as you encounter registration for the first time in your life, you come up with a password. During the second registration, you do not waste time and use the password you have already created. And so on.
This continues until one of the sites refuses to accept your password, citing poor password complexity. Then there are 2 options: you come up with a more complex password, or you modify the first password by adding additional numbers and symbols to it.
This approach has 2 problems:
At some point, you will start to get confused about which version of the password is: where is just a password, where is it with numbers, where is it with symbols.
Sooner or later, hackers will hack one of the “insignificant” sites and find out your password. This could be some old forum where you quickly registered in order to get some information just once. And in the end, the hacker will receive the same password that you use in your email.
The problem of tricky algorithms instead of password managers
There is a clever way to use different passwords everywhere and remember everything without a password manager. You just need to come up with your own password generation algorithm.
For example:
for google.com password: goo-bob-com
for the password from wikipedia.org: wik-bob-org
for the password from habr.ru: hab-bob-ru I think the point is clear. Problems begin when:
you need to change your password to a new one
twitter.com has been renamed to x.com, and the password x-bob-com is too short for the system
some system asks for numbers
some system does not support the symbol “-” Even if you figure out how to solve all these problems at the very beginning, during operation new problems will emerge that will force you to enter versions and get confused about which resource has which version. And when revealing your algorithm (if someone sees your password and guesses the generation algorithm), you will have to remember all the places where you are registered, go there and change the passwords to some newer algorithm.
There were also options to wrap these passwords with hash functions. Be it a regular sha1 or a more advanced self-written script.
I don’t know about others, but I often have to enter passwords in front of other people. It could be a meeting, a presentation, or simply a colleague came up to my work place and asked me to look at something, and I was not authorized. It turns out that I have to open the sha1 generator online, enter the password there in clear text (or even in closed form), copy the result and paste it into the password field? Don’t you think that the person standing next to you will immediately understand your system?
What are we trying to protect?
Many people wondered why such a “complex” and reliable system was needed for ordinary people. What exactly to protect? After all, an ordinary person does not have secrets worthy of such a reliable system.
I agree with this. I also don’t have anything so valuable that it would be hidden so much that Google itself, with all its power, would not be able to open it.
But I, like each of you, have something else. This is your personality.
It’s very rare that someone tries to hack you to get secrets. But much more often they do this in order to:
Conduct DDoS attacks from your IP on your computer’s power
Send spam and phishing emails from your mailbox
Write on your behalf to your contacts in instant messengers asking to borrow money
Take out a loan in your name
Buy goods online through your account with a linked card
Any other criminal activity that will hide the real identity of the villain with your name.
The web is less reliable, but more convenient
Many found bitwarden to be less secure than keypass.
These are password managers. The difference is that the password database from bitwarden is stored in the cloud with your uncle, and the database from keypass is located locally on your device without the intervention of third parties.
In the case of keypass, users upload a copy of the database to dropbox or a similar third-party file storage for ease of database availability and automatic backup.
Both managers encrypt and decrypt the password store locally as needed, and no third party can see the passwords themselves.
Both managers are open source and can be tested for client-side bugs.
In bitwarden, a normal use case can be considered a web client that is located on third party servers. Because of this, the client can be quietly replaced by one that snoops on your passwords. Here keypass really turns out to be a leader in security. But bitwarden takes the lead in terms of convenience – you don’t need to install the client, it’s always at hand on any device in the world.
How likely is it that bitwarden will host a fake client on its servers? I think this is only possible if you keep a secret that is worth more than the entire company, when bitwarden himself is ready to sacrifice his reputation and ruin his creation and his business for the sake of your secret. So, if you are not going to store the password for a bitcoin wallet with a billion dollars, you can safely use bitwarden.
Brute force will not help you
Another thing that confuses people is a lack of trust in hashing algorithms or a complete lack of understanding of how it even works.
In a previous article, I added a password strength table, saying that a 14-character password would be strong enough. Spoiler – 6 characters are enough with the correct configuration of the hashing algorithm.
Let’s figure out how file encryption works in general.
For this purpose, a symmetric block encryption algorithm is used. Most often this is AES (Advanced Encryption Standard). It encrypts blocks using a key. The key is not a password and must meet the requirements of the algorithm, for example, it must be of a certain length (for example, exactly 256 bits). This algorithm must be fast, otherwise the encrypted data will be difficult to work with.
How difficult it is to brute force a 256-bit key is described in this video.
Since keeping keys in your head is inconvenient, there is a way to turn a password into a key. This method is called hashing.
At the input, the hash function takes a password of any length (be it 1 character, or a 10-terabyte random file) and at the output gives us a 256-bit (or any other, if necessary) key. (yes, there are possible collisions: perhaps a 10 TB file will have the same hash as some 50-character password, so there is no point in 10 TB passwords)
Now let’s return to the table from the previous article. It gives an example where a brute force system can generate and check approximately 500 billion password options per second. In my opinion, this is very daring power (I once tried to brute force a password from a zip archive. With the participation of a video card, the performance was only about a million brute force attempts per second. In the end, I never found the password)
A little earlier I spoiled that even 6 characters can be enough. The secret is in the hash function. There are the famous MD5 and SHA1, which really work fast, but are considered unreliable.
Password managers, at a minimum, use the PBKDF2 hash algorithm. The speed of key generation using this algorithm is reduced to hundreds per second (i.e., not 500 billion passwords are checked per second, but simply 500).
But even here, many will say that technology is developing, and today it is 500, and tomorrow with new video cards it will be 500 billion.
First, let’s ask ourselves again whether our database of passwords is really so valuable that it would involve entire data centers in decryption.
Secondly, if the password is 14 characters, then in the next 10 years not a single data center will calculate it.
Thirdly, there are other hash algorithms. For example argon2id. Its trick is that to calculate the key it needs a given amount of RAM and processor threads. If you try to brute force this function on video cards with 100500 cores, you will run into RAM.
It turns out that with a good, heavily configured hash function, brute-forcing a 6-character password can take about the same amount of resources as a 14-character password with a simple hash function would require.
And the combination of a good hash function with a 14-character password will theoretically allow us to sleep peacefully for the rest of our lives.
About quantum computers
They won’t help you either. They are good for finding the pairwise key of asymmetric encryption (when you have the public key in your hands and want to calculate the private one). But quantum computing is completely useless in symmetric encryption, because… there we work not with an equation, but with an algorithm.
About the soldering iron
I don’t know why, but the setup was often criticized for the fact that it would not protect against physical threats to obtain the master password.
I repeat: we are not protecting a Bitcoin wallet with a billion dollars, but our own identity. I don’t think anyone would use a bat to spend a round sum of money through your online bank to cover the trail of money laundering from the sale of processors to North Korea. It would probably be much easier for these purposes to use a bottle of vodka and a random janitor from the outback.
Keyloggers
Strange, but there were practically no comments on this obvious and simplest type of hacking.
Logging all keystrokes is perhaps the easiest way to get a master password from a password manager. Moreover, this method just as easily compromises “horcrux” passwords when we add a piece from our head (for example, bob) to the password copied from the manager. Our accounts are still protected by two-factor authentication, but the meaning of “horcrux” passwords has been lost.
The fact that my system is vulnerable to keyloggers made me think and reconsider the method of accessing the password manager:
1) Try not to use a password manager on unfamiliar devices. Usually you have your phone handy, and it’s better to look up the password from there.
2) In some cases, use the sending function. In bitwarden you can create a link, following which you can read important information, for example a copied password. After opening the link, the data is deleted and the link does not work again. Then you won’t even have to enter anything on dangerous devices. But no one has canceled logging behind a clipboard, so it will not add security (but it will add convenience, since writing a random password with complex characters from a phone is a difficult task)
3) Use PIN codes to unlock the password manager on your own devices. In the case of a keylogger, this can protect the password database itself. If one of the PIN codes slips out of your head, you can log in with your password and set a new PIN. If someone tries to guess the pin, then in the case of bitwarden he will only have 5 attempts, after which he will need a master password. Yes, it can compromise your password, but it’s not that common and ideally you shouldn’t have spyware on your device. But in any case, this layer adds at least a little extra security.
Passwordless authorization – WebAuthn
Another thing that was practically not touched upon in the comments is passwordless authorization. And it’s strange. The thing is being boosted by Google and gaining popularity.
Solves the problem of keyloggers – you do not need to enter a password. It’s like ssh authorization using a key. In the case of the web, the key can be stored either on a physical device (for example yubikey) or in the password manager itself (I don’t know about others, but bitwarden has this).
Unfortunately, at the moment there are few sites that support passwordless authorization. More often, the same yubikey can only be used as a 2FA, and only as an additional 2FA, after TOTP 2FA is already connected.
New ideas
In addition to comments that discussed my setup, there were also comments describing other people’s stages. I liked many things.
Keypass web
I’ve never studied this issue, but it turns out that dozens of popular keepass variations also have their own autonomous html versionworking in any browser locally and without the Internet.
Such a solution would be ideal for my stage, because… there are already html versions of bananasplit and picocrypt.
With keeweb, the technology zoo would be limited to just html files and Aegis 2FA. (the separate password manager disappears). At the same time, everything out of the box turns out to be cross-platform and portable (no installation required).
It would be nice to replace the TOTP generator with an html one and generally have a universal set. Although questions might arise as to whether multifactoriality has been lost if all the eggs are in one basket under different passwords, but this is a topic for a separate discussion.
Git storage
At my stage, creating backups is a periodic manual process.
If bitwarden is replaced with a password manager with a local database, then its backup can be implemented via git. The bonus is that in addition to a self-hosted git server, you can use cloud solutions. The synchronization process can be easily automated.
Alternatively, you can use syncthing for synchronization, but in it you most likely will not have access from the web.
In any case, all this is relevant only with a local password database, so I will have to do backups manually the old fashioned way.
