
Password Cracking AES-256 DMGs and Epic Self-Pwnage - erik
http://blog.whitehatsec.com/cracking-aes-256-dmgs-and-epic-self-pwnage
======
Osmium
I am not a cryptographer but:

"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?

~~~
nwh
> 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.

<http://bojinov.org/professional/usenixsec2012-rubberhose.pdf>

~~~
Osmium
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?

~~~
nwh
I wasn't able to find a proof of concept of the password system, is there one
available publicly?

~~~
stcredzero
Keepass

------
Sami_Lehtinen
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.

------
thomas-st
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'

Also, everyone else seems to be using way fewer iterations, e.g. 5000 for
LastPass ([http://helpdesk.lastpass.com/security-options/password-
itera...](http://helpdesk.lastpass.com/security-options/password-iterations-
pbkdf2/))

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.

~~~
oakenshield
> I wonder if the C implementation is much faster

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.

OWASP recommends over 100k iterations too:
[https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet...](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Rule_3:_Iterate_the_hash)

~~~
thomas-st
True, looks like it's important to use a C module if available:

In [13]: from M2Crypto.EVP import pbkdf2

In [14]: %time pbkdf2('mypassword', open('/dev/urandom').read(16), 250000, 32)
CPU times: user 1.16 s, sys: 0.02 s, total: 1.18 s Wall time: 1.18 s

~~~
oakenshield
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.

[1] on modern hardware, that is.

~~~
jgeralnik
Using a slow implementation of PBKDF2 is not going to slow down attackers who
use a fast implementation.

~~~
oakenshield
Correct. I didn't mean slow implementation, I meant slow enough on modern
hardware using the fastest implementaiton.

------
mrgriscom
Another way to back up your master password is with 'ssss'.

<http://point-at-infinity.org/ssss/>

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.

------
oakenshield
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?

~~~
nwh
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.

------
stcredzero
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.

~~~
apawloski
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].

[1]
[https://github.com/magnumripper/JohnTheRipper/blob/unstable-...](https://github.com/magnumripper/JohnTheRipper/blob/unstable-
jumbo/src/keepass2john.c)

~~~
StavrosK
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.

~~~
apawloski
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.

~~~
StavrosK
Interesting, maybe I was doing something wrong. I was just using the package
provided by Ubuntu.

~~~
apawloski
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.

You can download that version here:
<https://github.com/magnumripper/JohnTheRipper>

Then you can build it with CUDA or OpenCL, SSE, OpenMP, MPI, etc., support
using the Makefile.

~~~
StavrosK
That's fantastic, thank you for the link.

------
neya
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!

[1]<http://www.truecrypt.org>

~~~
jamoes
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]

[1]: [http://www.privacylover.com/encryption/analysis-is-there-
a-b...](http://www.privacylover.com/encryption/analysis-is-there-a-backdoor-
in-truecrypt-is-truecrypt-a-cia-honeypot/)

------
amper5and
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.

------
Pinatubo
I love how those BJJ guys manage to work it into every conversation.

