Risk of bruteforce

Help
1

By reading this and other discussion on this forum, I’m also a bit worried about the possibilities of brute-force attacks to a container in the cloud. Computational power is available to people needing it. And for weak passwords, less power is required.

There just recently were similar discussions around similar technologies for password managers like LastPass (got hacked) and 1Password. I’m no security expert, but from my understanding following those discussions, the differences between both implementations were exactly this: while 1Password does combine a possible weak user password (because you wanted to keep it simple by design) with a random additional key to be stored separately by the user (or in their cloud). It was seen as much more secure now as LastPass which is open to brute force attacks of their offline containers.

Why does the 1Password architecture seem as a good approach? Users have to enter their passphrase, which get’s combined with the really-random-long security key as a second factor stored in eg Keychain or their cloud server making up the real thing, so the possibility of a weak password is 0.

Me too: I’d like to have a container, which is not vulnerable to brute force attacks of any kind and has protection agains user errors. And one of the biggest weaknesses is the user.

One could leverage the concept from 1Password with Cryptomator. It seems it is proven now for years.

But maybe I’m completely on the wrong thinking trying to understand the technology.

2

Hi.
My thoughts on this.

Cryptomator is using scrypt for the key derivation function to protect against brute force.
See also here: Security Architecture — Cryptomator 1.7.0 documentation.

Nevertheless is a weak password always a risk and I agree with you, the most risky factor is the user.

Cryptomator does the same thing (see link above). But I disagree with your last assumtion. You are mixing up the phrase that is actually used to encrypt something with the password someone has to use to generate this phrase. So even with the longest key for generated for encryption, you do not mitigate the risk that comes with a weak password. Its like having a bomb-safe door with a gumball-machine key.

3

Hi, I’d like to come back to this again, just to verify my security thinking about, as I still find it not clear enough and it’s still puzzling me.

This is for brute-force attacks on a Cryptomator vault, where the attacker has access to the files on the filesystem. This includes the masterkey file!

Is it correct to assume, that a brute force attack is possible, if a user has a weak password, by guessing that password, the attacker gains access as he can combine now successfully with the masterkey and decrypt?

The 1Password approach to me looks different. Again: attacker has access to the 1Password vault on the filesystem, but there is no the 1Password “masterkey”. Now, even when guessing the users’s password, a decryption is NOT possible, because the masterkey is still not available, simply because it’s not stored together with the vault!

So my point is: with access to the encrypted vault, an attacker could be successful with a dictionary attack, on Cryptomator, while it would be factors more complicated for solutions like 1Password, which stores the masterkey either in the users keychain (on Apple devices) or somewhere else, which usually requires another user password/biometrics, etc and another mechanism to unlock. So it’s like having another second factor.

Therefore my question: would it be possible to untangle the storage destination of the masterkey from the vault?

Or if not: could you please explain, why you believe that storing the masterkey together with the vault doesn’t decrease security?

Or to replicate you last statement: it sounds like you do have a bomb-safe door, but a nice entry keyhole available to everybody to unlock that door, while others seem to direct you to a different place to get another key for their complex keyhole in the bomb-safe door.

4

I will try to sum it up a bit to help you get an answer from the devs.

TLDR: Just choose a strong password for your cryptomator vault and you are fine. The encrypted data is safe with a strong password a second one doesn’t improve the security.

Cryptomator:

User Password (can be 1234) ⇒ decrypts “Masterkey file” by using scrypt (scrypt slows down automated brute force) which is stored in an encrypted form in the vault. ⇒ The result of the first decryption is the Masterkey ⇒ This Password/Key is used for decrypting the files in your vault.

The weak spot in this chain is potentially the users password. when chosen very weak. But when you are using a proper password the scrypt implementation is good enough to slow brute force down so an attacker would not be able to try out enough combinations to succeed in a reasonable time.

1Password:

1Password does the same thing. They use PBKDF2 instead of scrypt but also the users password (here comes the catch you are referring to) is used to decrypt the vault key which is saved in an encrypted form on the server as well. But the decryption of that vault key happens on your device as well. All data is handed to the client after different steps of authentication and decrypted locally.

The users password at 1password is constructed of your actual manual entry that you enter into the password field, plus an account password (they call it secret key) that is only required the first time you register your app with the service. Afterwards the App has a saved token that it can show to the server to prove that the authorisation via secret key + user password has been performed.

So, what 1Password does: They require your Password which can be 1234 and a password that is automatically generated when the account is set up. So even with the most weak password an attacker would always have to enter the always strong account password + the users password.
So if you choose a strong password yourself for 1Password you end up with an 2 times the age of the universe cracking time instead of 1 times the age of the universe cracking time. Which doesn’t matter in my opinion.

They did this because their online service is a single point of access to all the vaults off all the users. And this password field is the intended front door to everything. They simply wanted to safe themself from bad press because average users use the name of their cat as a password an get hacked. So, they enforce a very strong password. And the user has still the option using his/her favorite insecure password without risking the reputation of the service.

Since the vaults in cryptomator are generally saved in an password protected cloud drive which the average attacker doesn’t know. The attacker first has to get over that hurdle to get the encrypted vault. After that he/she has to crack the password of the vault itself.

Yes, a second password would open some more flexibility for special use cases, but all those can be handled otherwise as well and the implementation of a second password would change a lot in the overall encryption structure of the vault. A Pin protection for the app would be something that could solve the itch likewise to the mobile app, but this also is not a real security benefit more a feel better utility.

3 Likes
5

Perfect!

Thank you very much for the explanation!

I was actually more interested in these special cases, and would still appreciate it for the future if you could save the masterkey separately and not leave it with the vault.

I think the assumption that a vault is always additionally secured via the cloud provider is misleading, because almost all providers then cache the data locally on the target device, so that in the event of an attacker access it is easier to access the data from the target device instead of from the storage point in the cloud.

Also thank you for the detailed technical comparison with 1Password.

Thus, ultimately everything depends on the delayed verification by script in SW. I would welcome in the future a documentation in which this delay (in msec) is documented given examples of common password complexity on current hardware to provide users a guideline. And as I said a separation of the masterkey at least as an option would be very welcome, because without masterkey file the possibility is already prevented from the outset.

One possibility of where all this might fail (and unfortunately there were examples of this in the past) is late exploitation of programming errors (in this case the scrypt library) or other computing powers that are not yet known today.

Admittedly: certainly not interesting for the majority of users, but for a certain percentage of users perhaps it is. My scenario for example is a stolen destination drive or hardware where the attacker hast attack to the vault.

6

If you are using desktop, you can store the Masterkey file anywhere. If you open a vault and Cryptomator does not find the Masterkey file, it will ask where to find it.

Please note that this will not work with the mobile apps. At least not with the iOS app with which I tested it just now.

7

I don’t know why there is so much obsession with this masterkey file. It doesn’t influence the security if that file is on your vault or not. It is just a helping tool to make the decryption of the actual data files faster.

As mentioned the masterkey file is encrypted with a key that is derived from your password and to make it harder against dictionary attacks with a salt by using scrypt.

That calculation takes a few milliseconds depending on the amazing of rounds and the hardware I would assume 500 or something similar for the normal user this doesn’t matter since the calculation has to be done only once after entering your password.

But for a brute forever attacker it means only two guesses per second per instance instead of multiple thousand per second.

Now you have decrypted the longer key and some additional information in the masterkey file that is held in the RAM of your PC there is no decrypted version of that file on your hard drive that can be stolen.

But with this long key in your hand you can very swiftly decrypt other data without always having to go through the calculation of the scrypt algorithm. But since the key is extremely long it doesn’t matter. Since you have even more combinations to guess.

Additionally the masterkey file is important when it comes to Cryptomator hub where multiple people with different accounts want to access the same vault. Now an admin can place multiple masterkey files with the same content but with different encryption key to decrypt them. This can be done with public/private key pair so the admin doesn’t need to know the password the actual user uses to unlock their version of the vault.

May be it gets more visible like this:
Imagine you have a room with 100 super safe doors and you have a key. But that key does only open door 1 instead of all of them. But behind door 1 is a key that opens the other 99. Each door isn’t less safe due to that fact. And to make the analogy complete: breaking the door physically is not an option the only option is to craft new keys and try if they open the door. But there is one difference: Door 1 has a key lock that uses a possibly shorter key with less combinations but takes 10000 time longer to react on the key. But you actually don’t know the length of the key so you have to assume it is very long if you don’t have a reason to believe it is short.

So, you have the choice to guess keys that are possibly shorter but you have to behave as if they are also long and you need way longer to try them all. Or you directly try to craft the the key long key of the other doors of which you know the length and you for sure know it is long.

In that case it doesn’t matter if you try to craft the key for door one to get the key for the other doors or if you directly try to craft the key for door 2 - 99. The work you have to put into it is the same. But actually if you know the key for door 1 is as long as the key for the other doors it would be way smarter to attack the doors directly because you can try the keys way faster.