When i was created this topic i got some similar recommendations, one of them that is a video with scrypt that it was not clear to me how exactly it was protected from brute force attacks and another topic giving very easy instructions on a user on how to brute force the app.
To be honest it was something that i didn’t expect to work with Cryptomator.
Relaying on big and complex passwords is not enough on our modern days with a ton of power brute forcing options especially for big corps. Most apps start adding brute force quantum protection.
Can anyone please provide more details on how Cruptomator is protected from Brute force attacks?
Regarding the tool you linked: If you don’t have additional knowledge of the password (e.g. “the first char was a digit, then there were three lower case letters and the last character is a question mark”), cracker does not make a better job than simple brute forcing. And bruteforcing can take a long, long time:
We want to crack the password: Julia1984
In traditional Brute-Force attack we require a charset that contains all upper-case letters, all lower-case letters and all digits (aka “mixalpha-numeric”). The Password length is 9, so we have to iterate through 62^9 (13.537.086.546.263.552) combinations. Lets say we crack with a rate of 100M/s, this requires more than 4 years to complete.
And the above calculation does not even account for scrypt. You can read our docs for more info about the security architecture of Cryptomator.
But instead of brute forcing the password, which is very hard due to scrypt, you can directly brute force the encryption masterkey. It is 256bit long and encrypted with AES-256, which is assumed to be quantum save for a long time.
The Password length is 9, so we have to iterate through 62^9 (13.537.086.546.263.552) combinations.
The attacker would not know the password length is 9. It could be 6 characters, it could be 40 characters, it could be 11 characters, and on and on. However, it is also inaccurate to suppose the attacker would have to try every single combination before finding the password or passphrase.
Regarding Cryptomator’s use of Scrypt, which CPU cost and memory cost parameters does it use? I do like how KeePassXC lets me adjust to my liking these parameters for the Argon KDF.
The first two can also be found in our docs (linked above).
These parameters cannot be adjusted by the user. Allowing configuration also introduces user insecurities and misconfiguration and it is the goal of Cryptomator to offer easy-to-use, safe encryption.
Using a text editor, I opened the masterkey.cryptomator for one of my vaults just now and noticed the cost parameter is double the 16384 you state, meaning 32768. What would cause the work factor in this case to be doubled? Not complaining about it because I always prefer more security whenever possible.
