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.
Yet another reason to use lastpass 
Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 59. (Read 482537 times)
April 18, 2013, 04:49:38 PM
April 18, 2013, 04:31:34 PM
Please take a look to a post related to the real blockchain.info ip addresses.
https://bitcointalksearch.org/topic/blockchaininfo-development-bounties-135336
https://bitcointalksearch.org/topic/blockchaininfo-development-bounties-135336
April 18, 2013, 03:51:57 PM
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?
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.
April 18, 2013, 02:43:55 PM
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.
April 18, 2013, 02:26:20 PM
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...
April 18, 2013, 01:06:07 PM
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. 
April 18, 2013, 12:40:11 PM
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
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.
April 18, 2013, 12:32:37 PM
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
I disable Lastpass for the site. Seems dangerous to use it- no? I don't trust LastPass that much!
April 18, 2013, 12:31:02 PM
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
April 18, 2013, 11:47:40 AM
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
April 18, 2013, 11:43:52 AM
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
April 18, 2013, 11:34:04 AM
Approximate ETA 30 minutes - 1 hour.
Still down for me. Is it still down for everyone else as well?
Yep
April 18, 2013, 11:32:12 AM
Approximate ETA 30 minutes - 1 hour.
Still down for me. Is it still down for everyone else as well?
April 18, 2013, 11:25:40 AM
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). 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.
April 18, 2013, 11:21:19 AM
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. April 18, 2013, 11:13:02 AM
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.Also for clarity can you state how 2 level encryption could have possibly helped this scenario?
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.
April 18, 2013, 11:09:38 AM
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.Also for clarity can you state how 2 level encryption could have possibly helped this scenario?
April 18, 2013, 11:01:41 AM
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).
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?
April 18, 2013, 10:57:17 AM
Geeze only 98% saturation??? You could still shovel a page or two out with that!! *ducks*
April 18, 2013, 10:52:36 AM
Thanks for the update Piuk, hopefully the site is back up soon. 
Jump to: