![]() ![]() News flash: there are plenty of users out there not realizing that OpenSSL command line tools are insecure and not actually meant to be used. OpenSSL developers are aware of this issue but:Īt the end of the day, OpenSSL is a library, not an end-user product, and enc(1) and friends are developer utilities and “demo” tools. However, the password-to-key conversion performed by the openssl enc command is even worse than what Firefox password manager does: it’s essentially a single MD5 hash operation. For example, if you want to encrypt a file you might be inclined to use OpenSSL command line tools. Of course, it would be nice to see NSS implement a more resilient algorithm like Argon2 but that’s wishful thinking seeing a fundamental bug that didn’t find an owner in nine years.īut before anybody says that I am unfair to Mozilla and NSS here, other products often don’t do any better. NSS library implements PBKDF2 algorithm which would slow down bruteforcing attacks considerably if used with at least 100,000 iterations. So, is this issue so hard to address? Not really. That’s also at least how long software to crack password manager protection has been available to anybody interested. Turns out that the corresponding NSS bug has been sitting around for the past 9 (nine!) years. But finding a considerably stronger password that you can still remember will be awfully hard. Sure, you could choose a stronger password. If you do the math, cracking a password will take merely a minute on average then. In order to guess a 40 bit password you will need to test 2 39 guesses on average. This article estimates that the average password is merely 40 bits strong, and that estimate is already higher than some of the others. And humans are remarkably bad at choosing strong passwords. That means testing 8.5 billion password guesses per second. Judging by the numbers from this article, a single Nvidia GTX 1080 graphics card can calculate 8.5 billion SHA-1 hashes per second. The problem here is: GPUs are extremely good at calculating SHA-1 hashes. Out of the roughly 320 million hashes, we were able to recover all but 116 of the SHA-1 hashes, a roughly 99.9999% success rate. Anybody who ever designed a login function on a website will likely see the red flag here. However, when I looked into the source code, I eventually found the sftkdb_passwordToKey() function that converts a password into an encryption key by means of applying SHA-1 hashing to a string consisting of a random salt and your actual master password. ![]() Quite remarkably, I haven’t seen any articles stating the opposite. On the other hand, it is commonly believed that with a master password your data is safe. While they will still be encrypted in logins.json file, the encryption key is stored in ke圓.db file without any protection whatsoever. It is common knowledge that storing passwords there without defining a master password is equivalent to storing them in plain text. And modern hardware is very good at validating guesses.Ĭase in question: Firefox and Thunderbird password manager. Somebody who gets hold of that encrypted data will try to guess the password you used to protect it. There is a weakness common to any software letting you protect a piece of data with a password: how does that password translate into an encryption key? If that conversion is a fast one, then you better don’t expect the encryption to hold. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |