"We’re talking even 6 characters or longer, some upper and lower case, and maybe toss in a digit and special character."
6 characters? for 256-bit AES? That seems woefully inadequate. Imagine, say, 72 possible characters (52 a-Z, 10 digits, 10 special characters). This gives a password length for "full" 256-bit security as at least 128*log(2)/log(72) = 42 characters. If I'm wrong about this, please someone correct me! Either way, "6 or longer" seems far too short. Have I missed something here?
As for this particular person's predicament:
I, too, have been in this situation. I couldn't recite my password to someone; I can only touch-type it. It's a bizarre situation to be in and I've very nearly forgotten it myself in the past. I find it's easier to stop trying in case you accidentally "overwrite" your muscle memory and just go back to it later. Most recently, it happened due to my keyboard being detected incorrectly on boot and it almost drove me mad until I realised it wasn't my own error but the keyboard. I suspect if I hadn't have realised I might've been in the same situation as the OP.
In any case, Apple's implementation of FileVault is closed-source (to my knowledge) so it should always be assumed that someone who wants access to your data badly enough can get at it. I don't think it's worth being this paranoid about (e.g. the OP storing passwords as flat-files in a 256-bit AES encrypted disk image instead of just using the system keychain which manages all that for you).
Edit: I did find this interesting:
"The reason it’s so slow is because your AES256-encrypted DMG uses 250,000 rounds of PBKDF2-HMAC-SHA-1 to generate the encryption key. The ludicrous round count makes it extremely computationally expensive, slowing down the HMAC-SHA1 process by a factor of 250,000."
It doesn't seem so ludicrous if it works. Does anyone know if this is standard behaviour for encrypted DMGs?
Usually encryption schemes use a key derivation function like PBKDF2 to "stretch" a user's password to generate 128/256 bits for the symmetric cipher. In this case, the attacker cannot bruteforce aes directly because the generated key is "randomly" selected from the impossibly large 256 bit key space. The attacker now must feed his password guesses through the key derivation function, which hopefully will slow the attacker enough that even the smaller space of memorable user passwords is too large to bruteforce.
It doesn't seem so ludicrous if it works.
No key derivation function will protect from very short passwords, which is effectively the scenario here as the author is helping the attacker narrow number of possible passwords to 22472.
As a side note, my interpretation is that the author's password is longer than 6 characters, and he cannot remember 6 of the characters.
> I, too, have been in this situation. I couldn't recite my password to someone; I can only touch-type it.
Reminded me of this; making password type authentication using a game. The person can authenticate, but don't have explicit memory of the password that they can vocalise or write down.
It's a great system. And easier than you'd think. It really takes only two days of logging-in to learn a random password; even a long one. After all, how often do you think about your password when you type it in? I imagine you only consciously think about it the first dozen times you type it, and after that it becomes muscle memory, regardless of whether it's a random password or a memorable one. If that's the case, why not just use a random password to start with?
Still, it's never good to encrypt everything with the same password otherwise you end up in the same mess as the OP. What's the point of a backup if it shares a common point of failure?
That is standard behavior for encrypted DMG's. It's standard behavior for almost all crypto to use a key derivation function when using a user supplied password as the "key".
Noticed the PBKDF2 in there, that is a key derivation function, given a password it will then spit out a 256 bit key to actually use for the encryption/decryption of the content.
42 charcters with 72 possible characters makes out: 748081489394439783757309593473860564114284655771100962350023529282082095306929075084411791515994615131061055794446336 combinations... that's 7.48... x 10^116
and with 6 characters it's 1.06... x 10^56
We're not even talking about 6 characters - the article says they reduced the search space to 22472 combinations, which is barely 3 characters. Yes, 3 char passwords are easy to crack, what else is new?..
This is exactly why I always keep paper backup of the master passkey. But, the paper backup is encrypted with light encryption. Why not to use strong one? It really doesn't matter, the master password is random string and 16 chars long. Then it's encrypted with simple phrase, using substitution, partitioning and transposition. After those steps, I'm confident that the password on paper is also utterly useless to anyone without knowledge how it is encrypted and what the simple pass phrase is. The backup key is also hidden outside any reasonable search area.
You could also utilize very simple methods like reversing case of random password, or swapping parts, adding or removing something you know. Like prefix to strengthen the password, you just always write passwordpassword (or something similar) and then add your real password. Without knowledge to the attackers now your 6 chars long f8Snb3 random password is 22 chars long. Don't use any of the schemes mentioned here, make up your own.
The password container software is configured to run about ~10 million streghtening iterations on the password before it's being used. This means that it will take about two seconds to verify one password. (Yeah of course depending from many factors.) - Password strengthening can be done using memory hard problems, like scrypt, which is way better than options which only consume pure processing power. (Read about memory hard problems)
You should also be aware of corruption risk of encrypted data. Therefore it's better to always have a off-site backup set with different encryption key(s). I usually do not renew both keys simultaneously, so I can reasonably recover from the backup even if I would lose the master key.
Of course you can also use indirect method, where you map to numbers and letters, pages, rows, char poses and therefore the password on the paper has absolutely nothing to do directly with your password. Do mapping so, that distribution is even and it's not clear that it's offset references. Then you just know, that when you pick (pdf/book/file,source code) X and start applying your code, you'll get your password.
Generally I have absolute minimum length for passwords 12 random chars and for master keys I prefer 20. For keys that I don't remember, I use 32 random. If you're using AES256 and prefer to have 256 bits of entrypy in your password, use fully random password of 40 characters (including large set of special characters) or more.
Giving password to lawyer is good idea if you want someone to have your password, in case something bad happens to you. Otherwise it's totally pointless. If I'm gone, my (private) data is gone, and that's it.
Are DMG passwords really going through 250,000 rounds of PBKDF2-HMAC-SHA1?
I've been using the Python PBKDF2 module with fewer iterations as it takes over 18 seconds to hash a password with 250,000 iterations on my 2.7 GHz Core i5:
In [1]: import pbkdf2
In [2]: %time pbkdf2.PBKDF2('mypassword', open('/dev/urandom').read(16), 250000).read(32)
CPU times: user 18.36 s, sys: 0.07 s, total: 18.43 s
Wall time: 18.45 s
Out[2]: '<>\x17\x03q+\x1d\x1c+\x94^\xa2\xc9&\xa9\xa56\xc2\xfa\x97A\xd7\xfb\xc8\x93r\x9d\xa0\xd67|\x1e'
I wonder if the C implementation is much faster, or if Apple uses some special hardware acceleration (GPU or special CPU instructions), as I'd love to increase the number of iterations in my Python application.
Very likely -- Run this on your machine and see if it improves things http://stackoverflow.com/a/9781943. I got about 18.6s for your python code while this one with a 16 byte salt and 250k iterations runs in 0.6s.
I may not understand the whole context, but if you're using PBKDF2 for key derivation, you don't want to use something that works "fast". You want whatever algorithm/iteration combination that is as slow as possible [1], but not too slow that it annoys the user.
The kdf should be as slow as possible for an attacker but fast enough for you. If you're using python and the attacker is using C, you can increase security with no usability loss by switching to C and raising the iteration count.
You can split a secret into N pieces, where any M of them are enough to reconstruct it. Even if you have M-1 pieces, you're no better off than a random guess. You can then distribute the N pieces in safe places and among trusted parties.
I just implemented this scheme thinking towards what would happen to all my digital data if I were to die or become incapacitated. I store much of my local data and account passwords with strong encryption, with full-strength keys (not six chars like the OP) that no one would be able to guess or brute-force.
The hardest part is really thinking through what the reconstruction threshold should be and who your trusted parties are. You want the threshold high enough that you would not be easily compromised if you misplaced your trust, but not so high to preclude recovery if any of your trusted parties lost their piece, or... both of you were taken out in the same accident.
You can also use a service like deadmansswitch.net to distribute additional pieces to people automatically if you don't check in for a certain amount of time. Another moving part, but it does increase the 'james bond' factor.
I've been thinking about this very problem---recovering a forgotten encryption password without trusting a third party. The state of the art seems to be
1. Print it out on paper and put it in a safe. This is somewhat annoying and inconvenient for the vast majority of users, and if you lose or don't have access to the paper, you're screwed.
2. Encrypt the password using answers to some security questions and store it with an online provider you marginally trust. This has the problem of reducing the security to the strength of your answers (which may be known to any number of people close to you), and people might even forget the spelling of their answers which puts them in the same pickle.
I feel what would be ideal is some sort of a question/challenge that evokes a consistent, unique, high-entropy response from the user but the response is not based on a fact... sort of like a Rorschach test, perhaps, but one where each user would have a unique response. Is anyone aware of some system/research like this?
You're better off just remembering the key to begin with. I can remember the ones I used in high school, and there's lots of simple methods of increasing your retention of them. Simplest of all is using them regularly.
KeepassX. You can use the same file on OS X, Windows, and Linux. Keep the file in Dropbox (it has its own encryption, independent of Dropbox) and you can access it everywhere, including iOS and Android, which also have Keepass implementations.
Keepass (and LastPass, etc) is vulnerable to the same problem -- if you forget the master password, you can get locked out of everything. While it is useful, it is not the only answer. If the encrypted information is mission critical, then you must have a paper backup of the password stored somewhere safe.
Then again, if you don't, there is also a keepass2john [1].
Is it just me, or is john very very slow? I remember trying MD5 once, but the tries per second were in the thousands (whereas GPU-accelerated crackers do billions).
Maybe I'm misunderstanding and it was a few thousand rounds of MD5, though.
John isn't always the fastest anymore, but it's definitely not very, very slow. It also provides the widest support by far. (And most of the formats are GPU accelerated, OpenMP threaded, or SSE parallelized. John itself also supports MPI. Make sure you've configured the makefile right.) If there's a format you're trying to crack, chances are john provides a convenient and reasonably fast way to crack it.
Not sure which one is in the Ubuntu repository. Although John the Ripper is Solar Designer's baby, most of the current development (under Solar's guidance) occurs in the "jumbo" version led by another developer named magnum.
If you want to maintain a better security setup than mentioned in the article above (and for Windows), you can use TrueCrypt[1], which has some nice schemes to protect your data, even if someone forces you to leak out your password. You can even maintain virtual drives that are completely encrypted and can be mounted when needed. Do check it out!
I am wary of truecrypt. It is open source, but the development is not open. It's also "exceedingly difficult to generate binaries from source that match the binaries provided by Truecrypt (due to compiler options, etc.)"[1]
I created http://passguardian.com for this sort of situation. You can use it to split a password into a certain number cryptographic shares, setting a threshold on the number of shares that should be necessary to reconstruct the password. Store the shares in different locations/with different people, and use only if needed to reconstruct the original password.
"We’re talking even 6 characters or longer, some upper and lower case, and maybe toss in a digit and special character."
6 characters? for 256-bit AES? That seems woefully inadequate. Imagine, say, 72 possible characters (52 a-Z, 10 digits, 10 special characters). This gives a password length for "full" 256-bit security as at least 128*log(2)/log(72) = 42 characters. If I'm wrong about this, please someone correct me! Either way, "6 or longer" seems far too short. Have I missed something here?
As for this particular person's predicament:
I, too, have been in this situation. I couldn't recite my password to someone; I can only touch-type it. It's a bizarre situation to be in and I've very nearly forgotten it myself in the past. I find it's easier to stop trying in case you accidentally "overwrite" your muscle memory and just go back to it later. Most recently, it happened due to my keyboard being detected incorrectly on boot and it almost drove me mad until I realised it wasn't my own error but the keyboard. I suspect if I hadn't have realised I might've been in the same situation as the OP.
In any case, Apple's implementation of FileVault is closed-source (to my knowledge) so it should always be assumed that someone who wants access to your data badly enough can get at it. I don't think it's worth being this paranoid about (e.g. the OP storing passwords as flat-files in a 256-bit AES encrypted disk image instead of just using the system keychain which manages all that for you).
Edit: I did find this interesting:
"The reason it’s so slow is because your AES256-encrypted DMG uses 250,000 rounds of PBKDF2-HMAC-SHA-1 to generate the encryption key. The ludicrous round count makes it extremely computationally expensive, slowing down the HMAC-SHA1 process by a factor of 250,000."
It doesn't seem so ludicrous if it works. Does anyone know if this is standard behaviour for encrypted DMGs?