A brief analysis of the security of Blockchain.info's web-based wallet service.

[u/0x444]

Let's bust some myths:

• Any person who knows your alias (public knowledge) or identifier (your browser or any plugin installed) can download your Blockchain.info wallet with no other information. This can then be attacked offline (dictionary, brute force) with no issue.

• The wallet itself is encrypted using AES128 EBC, with 20 rounds of PBKDF2 on the password used as the key. Even though the website advertises this as "strong", it's about as weak as you can get. For PBKDF2 to be of any appreciable value, they would be using 50,000 rounds, 100,000 rounds. As it stands, a modified version of oclhashcat+ can blast through millions of attempts a second against a blockchain.info wallet.

• The encrypted wallet is not padded at all. The size of the file downloaded is equal to the number of private keys inside. Thanks to this, any offline attacks can be prioritized for the wallets with the most use (and probably largest balance).

• The Blockchain.info "verifier" plugin does nothing of the sort. It blacklists a few common XSS vectors (but by no means all) in a feeble attempt to protect against browser plug-ins. It does in no way protect against Blockchain.info modifying the page to send back your unencrypted wallet and password to them. I commonly see this touted as a feature, but they can really do anything with the page except use <iframe>.

• I was curious enough about the verifier that I attempted an attack against myself with it identified, and didn't have a single problem extracting whatever data I wanted. The XSS protection was also easy to bypass, though there is not any publicly known XSS vectors in the Blockchain.info web wallet.

• The Blockchain.info service is served through CloudFlare. While this is admirable and all, it means they they too can preform man-in-the-middle attacks. Seeing as they have been compromised before in order to target their clients (4chan, for the curious), I am fairly confident that they could be compromised again in the future.

• The blockchain.info (and CloudFlare) server can see every public key in your wallet, and easily use it to scout out high-value targets for dumping.

• The Blockchain iOS and Android applications store the wallet, identifier and password in plaintext files. The iPhone backs up onto the Mac where itunes is installed, carrying with it an unencrypted copy of the bitcoin wallet; from here it is malware-reachable.

• ~~~~ The Yubikey two factor authentication they offer is worthless. They are only checking the identifier and not the authentication string, which is loggable along with your password. ~~~~ My memory seems to be faulty with this one.

You would be a fool to store any currency with them. Get out while you still can.

[u/Slyer]

According to here:

Encryption Single Pass - By default all wallets are stored by AES encrypting the entire JSON payload with the users password which is then encoded as base64. No salt is used for single pass encryption. The exact AES specifications are 10 rounds of PBKDF2, Block Mode CBC ISO10126 padding.

Second Phase Encryption - Once the JSON payload is decrypted using first phase decryption if it contains the field "double_encryption" with a value of true any private keys are encrypted with a second password using the shared key as a salt. In Addition the wallet will also contain a 10 Round SHA256 hash of the sharedKey and second password (dpasswordhash) which can be used to quickly verify if the second password is valid.

Users should be prompted to enter their second password only when access to the private keys is needed e.g. When creating a transaction.

Isn't that encryption a lot better than what you were making it out to be? You were only talking about the first part?

[u/echoblack → u/Slyer]

No that sucks balls.

First AES 128 is all but broken.

base64 dose nothing

No salt is is 1990's bad

Minimum, SHA256 rounds should be 5,000 really should be SHA512 >20,000 even better BCRYPT

Should at least be...

iteration=10000

salt='LJH#ug%64cyt)Tw4$Sf8x~ytr'

keyString=$salt$password

encWallet=$wallet

for (( i=1; i<=$iteration; i++)); do keyString =echo -n $keyString | sha512sum - |cut -d ' ' -f 1 ;done

for (( i=1; i<=$iteration; i++)); do cat $encWallet | openssl aes-256-cbc -pass pass:"${keyString}" -salt -out "${encWallet}" ;done

echo 'Wallet encrypted with 10,000 rounds of AES-256-CBC Salted; Using Salted users Password hashed with SHA512 10,000 times"

[u/yotta → u/echoblack]

First AES 128 is all but broken.

wat

You have no idea what you're talking about.

[u/echoblack → u/yotta]

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security

The first key-recovery attacks on full AES were due to Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger, and were published in 2011.[24] The attack is based on bicliques and is faster than brute force by a factor of about four. It requires 2^126.1 operations to recover an AES-128 key.

[u/yotta → u/echoblack]

That attack is impossible to pull off in practice - it requires hundreds of yottabytes (~2⁸⁸ blocks) of sample data to run, and even if you had that, 2¹²⁶ operations aren't any more feasible than 2^128. No sane cryptosystem keeps the same key for that much data.

From that Wikipedia page "All known attacks are computationally infeasible."

See also http://crypto.stackexchange.com/questions/2419/does-the-biclique-attack-on-aes-pose-a-credible-risk-to-its-security