Blockchain.info - Bitcoin Block explorer & Currency Statistics

[ErebusBat]

Can you confirm that the server will NOT send the encrypted blob until 2FA is successful (assuming it is on of course)??

Also for clarity can you state how 2 level encryption could have possibly helped this scenario?

I cannot see how that is possible.  Everything happens in the browser.  So, I imagine, the encrypted blob must be sent to the browser once it visits the URL.

Then what is the point of 2FA?  In that scenario how does it protect you?  You can't base the encryption off the 2FA value because it is ever changing.

[talnted]

Thanks for the update Piuk, hopefully the site is back up soon. 

[centove]

https://i.imgur.com/R4i7ddC.png

Geeze only 98% saturation??? You could still shovel a page or two out with that!! *ducks*

[BurtW]

@piuk
Can you give your opinion on this?
https://bitcointalk.org/index.php?topic=173149.msg1816127#msg1816127
Is it possible?

The site has not been compromised in any way. I think some users are possibly using the same usernames on bitcointalk as alias's to blockchain wallets in combination with weak passwords and using the same password on other bitcoin sites.

As always I recommend to never reuse the same password on any other websites and to use the chrome/firefox browser extension (not the verifier).

Thanks piuk.  How do you think thieves are getting wallet URLs?  My friend never logged on since it was setup 6 months ago, and didn't use an alias (and has never heard of bitcointalk...).  Yet she had 7 coins stolen last week.  Lots of similar reports going round.

I do not know how they are getting the wallet URLs but I can verify that they have tried to hack into my wallet.  I know this because every time they try to do it I get a text message with a new 2FA code.  Has happened a few times.

As I understand it if a hacker ever does get your encrypted blob then they can attack it offline to their heart's content and with as much power as they can throw at it on a dedicated system, right?

So it is critical to have a very long random password on the encrypted blob.

Also, if you know (like I do) that they do have your wallet URL it might be a good idea to move to a new URL?  Is there an easy way to do this besides signing up for a new wallet?

[BurtW]

Can you confirm that the server will NOT send the encrypted blob until 2FA is successful (assuming it is on of course)??

Also for clarity can you state how 2 level encryption could have possibly helped this scenario?

I cannot see how that is possible.  Everything happens in the browser.  So, I imagine, the encrypted blob must be sent to the browser once it visits the URL.

Then what is the point of 2FA?  In that scenario how does it protect you?  You can't base the encryption off the 2FA value because it is ever changing.

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

[John (John K.)]

Can you confirm that the server will NOT send the encrypted blob until 2FA is successful (assuming it is on of course)??

Also for clarity can you state how 2 level encryption could have possibly helped this scenario?

I cannot see how that is possible.  Everything happens in the browser.  So, I imagine, the encrypted blob must be sent to the browser once it visits the URL.

Then what is the point of 2FA?  In that scenario how does it protect you?  You can't base the encryption off the 2FA value because it is ever changing.

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

[picobit]

Thanks piuk.  How do you think thieves are getting wallet URLs?  My friend never logged on since it was setup 6 months ago, and didn't use an alias (and has never heard of bitcointalk...).  Yet she had 7 coins stolen last week.  Lots of similar reports going round.

Reportedly, Google harvests all URLs pasted into Chrome (as the URL bar and search bar is the same, and their server determines if it is an url).  Possibly they also harvest URLs from Google Mail (when you email the url to yourself).  This is probably how 3000 Instawallet URLs became searchable on Google.

[zebedee]

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

That sounds sensible.  But if that's true (with the 2FA bit omitted in case of no 2FA), then brute-forcing passwords wouldn't work right? Unless blockchain.info is happily checking multiple failed login attempts (you'd hope it'd rate limit them).

[JonSnow]

Approximate ETA 30 minutes - 1 hour.

Still down for me.  Is it still down for everyone else as well?

[tiptopgemdotcom]

Approximate ETA 30 minutes - 1 hour.

Still down for me.  Is it still down for everyone else as well?

Yep

[willphase]

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

the source code is here: https://github.com/blockchain/My-Wallet/blob/master/wallet.js

the wallet clientside javascript sends the 2FA and the ID over and gets an encrypted wallet blob back - the password is never sent to blockchain.info

Sounds like enabling 2FA does defend against a certain class of offline attacks, especially when your wallet has an easily guessable identifier.

Will

[John (John K.)]

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

the source code is here: https://github.com/blockchain/My-Wallet/blob/master/wallet.js

the wallet clientside javascript sends the 2FA and the ID over and gets an encrypted wallet blob back - the password is never sent to blockchain.info

Sounds like enabling 2FA does defend against a certain class of offline attacks, especially when your wallet has an easily guessable identifier.

Will

Oh, I forgot this is open source. Thanks for the clarification - I was under the assumption that the PW hash are compared before the blob is even sent. Guess everyone should stick with long hard passwords now - a service like LastPass or KeePass would be useful.

[willphase]

Oh, I forgot this is open source. Thanks for the clarification - I was under the assumption that the PW hash are compared before the blob is even sent. Guess everyone should stick with long hard passwords now - a service like LastPass or KeePass would be useful.

Yup - this is also specifically stated in the help pages:

What if an attacker knows my wallet identifier?

If you do not have two factor authentication enabled, the attacker can gain access to your encrypted wallet data. The attacker can then attempt to decrypt your wallet by brute force. Whether or not the attacker would be successful depends on how secure your password is.

What it doesn't really emphasise is that wallet nickname == wallet identifier so if you've used e.g. a public wallet nickname (bitcointalk forum name) and haven't enabled 2FA then this does lower the bar for an attacker to perform an offline bruteforce.
 
Will

[tiptopgemdotcom]

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

the source code is here: https://github.com/blockchain/My-Wallet/blob/master/wallet.js

the wallet clientside javascript sends the 2FA and the ID over and gets an encrypted wallet blob back - the password is never sent to blockchain.info

Sounds like enabling 2FA does defend against a certain class of offline attacks, especially when your wallet has an easily guessable identifier.

Will

Oh, I forgot this is open source. Thanks for the clarification - I was under the assumption that the PW hash are compared before the blob is even sent. Guess everyone should stick with long hard passwords now - a service like LastPass or KeePass would be useful.

I disable Lastpass for the site.  Seems dangerous to use it- no?  I don't trust LastPass that much!

[John (John K.)]

I also want to know exactly how this works.  If the encrypted blob is just sent then all anyone ever needs to do is visit the wallet URL one time and they have your encrypted blob.

I would assume that the process goes like this:

a) ID and 2FA transmitted via plaintext (https of course), and the password is hashed before being transmitted.

b) Server compares the three variables (ID, 2FA, PW), if either one does not match (even if the other 2 matches), the blob is not sent to the browser.

c) Password at the local browser is used to decrypt the blob.

the source code is here: https://github.com/blockchain/My-Wallet/blob/master/wallet.js

the wallet clientside javascript sends the 2FA and the ID over and gets an encrypted wallet blob back - the password is never sent to blockchain.info

Sounds like enabling 2FA does defend against a certain class of offline attacks, especially when your wallet has an easily guessable identifier.

Will

Oh, I forgot this is open source. Thanks for the clarification - I was under the assumption that the PW hash are compared before the blob is even sent. Guess everyone should stick with long hard passwords now - a service like LastPass or KeePass would be useful.

I disable Lastpass for the site.  Seems dangerous to use it- no?  I don't trust LastPass that much!

I personally use Lastpass for the site, including a 2FA Gauth as I trust Lastpass.

[ErebusBat]

I personally use Lastpass for the site, including a 2FA Gauth as I trust Lastpass.

As do I.  If my LastPass is compromised I have more to worry about than my bitcoins.

[gbl08ma]

Blockchain.info seems down? I just get a CloudFlare page saying it's down and no cached version is available... right when I wanted to login to my wallet...

[JordanL]

To those who have lost coins from blockchain.info accounts; are you certain that you didn't enter your identifier and password into a phishing site? I saw an extremely sophisticated on many months ago, on a typo domain. I suspect that accounts for more lost coins than any actual hacking.

[piuk]

Can you confirm that the server will NOT send the encrypted blob until 2FA is successful (assuming it is on of course)??

Also for clarity can you state how 2 level encryption could have possibly helped this scenario?

Correct this is the primary purpose of blockchain 2FA. Which Scenario? It prevents someone being bale to attempt to bruteforce the wallet if they know the alias or guid.

Thanks piuk.  How do you think thieves are getting wallet URLs?  My friend never logged on since it was setup 6 months ago, and didn't use an alias (and has never heard of bitcointalk...).  Yet she had 7 coins stolen last week.  Lots of similar reports going round.

Could be many things. Is her PC clean? Is her email secure? She might have visited a phishing sites (some based on domain misspellings). Does she reuse the password on other sites?

Did she purchase and import the private key from somewhere? some sites encourage you to import a private key containing purchased coins.

What it doesn't really emphasise is that wallet nickname == wallet identifier so if you've used e.g. a public wallet nickname (bitcointalk forum name) and haven't enabled 2FA then this does lower the bar for an attacker to perform an offline bruteforce.

I think a good way to counter this would be for blockchain to recognise the browser the normally logs into the wallet and challenge unknown browsers by confirming an email or SMS code. This would place less emphasis on the need to keep the alias or guid secure.

[rme]

Please take a look to a post related to the real blockchain.info ip addresses.
https://bitcointalk.org/index.php?topic=135336.msg1877461#msg1877461