

An Empirical Study of Cryptographic Misuse in Android Applications [pdf] - nmc
http://www.cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf

======
tptacek
This is great: interesting systems research (reconstructing CFGs from
bytecode, converting to SSA, discovering type constraints for registers, and
slicing to find which code influences which registers) and a good starting
point for crypto security.

I'm particularly happy to see them pointing out how easy it is to end up with
ECB mode, which allows attackers who can merely influence plaintext to decrypt
messages a byte-at-a-time, "Hollywood-style". ECB is for Java the de facto
default, the one you get when you ask the JCE for "AES" without specifying a
block mode. This is no surprise: the other modes all need IVs and nonces, and
so libraries give you the one that doesn't need more options when you don't
tell it to. It's for this reason that we call ECB "the default mode"; it's a
quirk of ours, but a useful one. Don't use the default mode.

Here's the list of things they looked for:

1\. Don't use ECB

2\. Use random IVs for CBC mode (if you don't, you end up with ECB-like
properties for the first blocks of messages).

3\. Avoid constant encryption keys (if they're constant, they're trivially
discoverable by attackers, and encryption is cosmetic).

4\. Avoid constant salts for password-based key generation (so that attackers
can't precompute tables).

5\. Use at least 10,000 iterations for your KDF to slow down brute force
attackers.

6\. Don't pass static seeds to SecureRandom, which can have the side effect of
turning off cryptographic randomness, destroying the security of your system.

The one thing I'd caution readers about is to understand the limitations of
this analysis. The authors are demonstrating the power of a particular static
analysis technique, and also providing a useful survey of just how bad app
crypto is (over 80% of the thousands of apps they tested flunked these basic
tests!).

But that list above isn't "The Six Commandments" of good crypto; it's missing
extremely basic stuff, like never encrypting without authenticating, never
repeating a nonce or counter, &c. We set out to build challenges to capture
things we'd seen going wrong in real cryptosystems we'd tested, and we have
more than 64 of them now.

~~~
spikels
One of the many mistakes by Adobe revealed in the recent hack was their use of
ECB to encrypt passwords.

The basic problem with ECB is the same input always results in the same
output. And this applies not only to the entire input but specific subsections
of the input, known as blocks. This leaks substantial information.

In the Adobe leak accounts with identical passwords were easily identified as
they had the same encrypted password. Frequency analysis can then be applied
to find common passwords ("123456" is often the most common...). Even worse
Adoble also leaked the password hints so you often had thousands of different
hints to help you guess a single password.

Of course you should not even be encrypting password in the first place (use a
cryptographic hash with an individual cryptographically random salt for each
password NO! SCRATCH THAT. JUST USE BCRYPT!) but that's another issue...

[http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-
pass...](http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-
disaster-adobes-giant-sized-cryptographic-blunder/)

[http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#...](http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29)

Edit: Corrected based on tptacek's comment below.

~~~
tptacek
Salted hashes are a very poor way of storing password authenticators.

[http://codahale.com/how-to-safely-store-a-password/](http://codahale.com/how-
to-safely-store-a-password/)

There are much more significant problems with using ECB than simple frequency
analysis suggests.

~~~
spikels
I kinda expected you to correct me. You can't help yourself can you. :) And
that is a good thing. Thanks!

Sorry I was not trying to give the entire recipe for password handling. I was
assuming a KDF with lots of iterations. But perhaps you could clear up one
thing:

Assuming proper implementation (I know a big assumption) how is bcrypt better
than PBKDF2 with lots of iterations using a good hash and salt? At some bcrypt
cost and PBKDF2 iteration count wouldn't they be equally secure?

~~~
tptacek
PBKDF2 is straightforward to accelerate in commercial off the shelf hardware,
and bcrypt isn't. But both are fine. Neither are "salted hashes".

~~~
spikels
I guess I had my terminology wrong you would know better. I always thought of
PBKDF2 as simply "iterated hashing of a salted password".

~~~
B-Con
Your mental model isn't necessarily wrong.

The phrase "salted hash" generally refers to something more plain than PBKDF2.
PBKDF2 is technically a "Key Derivation Function", but it can also be used as
a "Password Hash Function". Password Hashes generally use a hash function and
a salt, yes, but they also incorporate other important factors as well,
commonly a work factor and some "hard" computational problem, so it's unfair
to call them merely a salted hash. PBKDF2, along with password hashes in
general, do indeed do everything a "salted hash" would do, but importantly,
they also do more.

------
adestefan
Their list of Rules is out of order and that may affect Table 3. Mainly I'm
wondering it there really are that many programs that use constant keys (e.g.
is Rule 3 in the table really Rule 3 from the text since that's called out as
rule 3 below.)

Of course it wouldn't suprise me one bit of there really are that number of
applications that use constant keys.

------
archivator
Excellent study! I know it's not exactly easy to do with their analysis
framework but I'd be interested to know how many apps just ignore certificate
errors. It's a depressingly common "solution" on Stack Overflow..

------
nmc
OK, sorry about the custom title, I got it from there:
[https://twitter.com/csoghoian/status/398336912181579776](https://twitter.com/csoghoian/status/398336912181579776)

