An Empirical Study of Cryptographic Misuse in Android Applications [pdf] | Hacker News Reader

An Empirical Study of Cryptographic Misuse in Android Applications [pdf]

cs.ucsb.edu

74 pointsnmc17 comments

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.

An example of "extremely basic stuff" is checking the domain entry in the SSL certificate, as bank ABN-Amro failed to realize [pdf] https://www.os3.nl/_media/2012-2013/courses/ssn/security_in_...

Since there are so many types of errors,the usual recommendation is to use a higher level library, like NaCl.

I wonder if using similar approach shown in this research ,one could determine if apps are using NaCl(say, for all outgoing communications). Such knowledge would be pretty useful to end users.

Ensuring that programs use NaCl should be much, much easier than verifying that they use the JCE properly, especially if you adopt the constraint that you only need to analyze JCE crypto.

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://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#...

Edit: Corrected based on tptacek's comment below.

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

http://codahale.com/how-to-safely-store-a-password/

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

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?

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

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

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.

Well-put as usual, tptacek. One quibble: What do you mean when you say 'constant' encryption key? Do you mean hard-coded in the source of an application?

"Constant" is their term, not mine, and does seem to refer to hardcoded keys.

Should the JCE API remove the call that allows one to ask for a modeless algorithm? I cannot imagine any cryptographically valid app that just picks a mode at random and tries to wing it.

Very yes.

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.

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

OK, sorry about the custom title, I got it from there: https://twitter.com/csoghoian/status/398336912181579776

Reply on news.ycombinator.com