Bitcoin Forum
April 23, 2017, 10:05:05 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 [114] 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 ... 169 »
  Print  
Author Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics  (Read 435619 times)
zebedee
Donator
Hero Member
*
Offline Offline

Activity: 670



View Profile
April 18, 2013, 01:58:53 PM
 #2261

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1492985105
Hero Member
*
Offline Offline

Posts: 1492985105

View Profile Personal Message (Offline)

Ignore
1492985105
Reply with quote  #2

1492985105
Report to moderator
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
April 18, 2013, 02:01:37 PM
 #2262

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.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
talnted
Full Member
***
Offline Offline

Activity: 236


www.bitcoingem.com


View Profile WWW
April 18, 2013, 02:52:36 PM
 #2263

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

The Original and Most Popular Gem Game: www.bitcoingem.com
Over 800+ BTC Paid Out!  1110+ Buyers of the Gem!
centove
Full Member
***
Offline Offline

Activity: 194


View Profile
April 18, 2013, 02:57:17 PM
 #2264


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

Give me Btc: 1BRkf5bwSVdGCyvu4SyYBiJjEjbNiAQoYd Mine on my node: http://ask.gxsnmp.org:9332/
BurtW
Legendary
*
Offline Offline

Activity: 1918

All paid signature campaigns should be banned.


View Profile WWW
April 18, 2013, 03:01:41 PM
 #2265

@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?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
BurtW
Legendary
*
Offline Offline

Activity: 1918

All paid signature campaigns should be banned.


View Profile WWW
April 18, 2013, 03:09:38 PM
 #2266

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
John (John K.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1134


Will read PM's. Have more time lately


View Profile
April 18, 2013, 03:13:02 PM
 #2267

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.

My BTC Tip Jar: 1Pgvfy19uwtYe5o9dg3zZsAjgCPt3XZqz9 , GPG ID: B3AAEEB0 ,OTC ID: johnthedong
Escrow service is available on a case by case basis! (PM Me to verify I'm the escrow!)

picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 18, 2013, 03:21:19 PM
 #2268

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
Donator
Hero Member
*
Offline Offline

Activity: 670



View Profile
April 18, 2013, 03:25:40 PM
 #2269

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
Member
**
Offline Offline

Activity: 112


View Profile
April 18, 2013, 03:32:12 PM
 #2270

Approximate ETA 30 minutes - 1 hour.

Still down for me.  Is it still down for everyone else as well?
tiptopgemdotcom
Legendary
*
Offline Offline

Activity: 1302


fine gemstones and jewelry directly to you


View Profile
April 18, 2013, 03:34:04 PM
 #2271

Approximate ETA 30 minutes - 1 hour.

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

Yep
willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
April 18, 2013, 03:43:52 PM
 #2272

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.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1134


Will read PM's. Have more time lately


View Profile
April 18, 2013, 03:47:40 PM
 #2273

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.

My BTC Tip Jar: 1Pgvfy19uwtYe5o9dg3zZsAjgCPt3XZqz9 , GPG ID: B3AAEEB0 ,OTC ID: johnthedong
Escrow service is available on a case by case basis! (PM Me to verify I'm the escrow!)

willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
April 18, 2013, 04:31:02 PM
 #2274

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
Legendary
*
Offline Offline

Activity: 1302


fine gemstones and jewelry directly to you


View Profile
April 18, 2013, 04:32:37 PM
 #2275

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.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1134


Will read PM's. Have more time lately


View Profile
April 18, 2013, 04:40:11 PM
 #2276

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.

My BTC Tip Jar: 1Pgvfy19uwtYe5o9dg3zZsAjgCPt3XZqz9 , GPG ID: B3AAEEB0 ,OTC ID: johnthedong
Escrow service is available on a case by case basis! (PM Me to verify I'm the escrow!)

ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
April 18, 2013, 05:06:07 PM
 #2277

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.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
gbl08ma
Sr. Member
****
Offline Offline

Activity: 306


Donations: http://tny.im/nx


View Profile WWW
April 18, 2013, 06:26:20 PM
 #2278

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
Donator
Sr. Member
*
Offline Offline

Activity: 294



View Profile
April 18, 2013, 06:43:55 PM
 #2279

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
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW
April 18, 2013, 07:51:57 PM
 #2280

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.

Pages: « 1 ... 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 [114] 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 ... 169 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!