HostFat
Staff
Legendary
Offline
Activity: 4270
Merit: 1209
I support freedom of choice
|
|
April 19, 2012, 03:17:18 PM |
|
It's likely that it'll be perfectly safe for a while, until some dodgy admin gets the idea to scrape all emails for keys and mtgox codes.
I think that this step will be enough for making it secure - When "claimed" the key is swept into a new bitcoin address. He can also add a warning on the email message that says something like: "Be sure that you have your computer secured, because unclaimed bitcoins can be taken by viruses and bad people"
|
|
|
|
rjk
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
April 19, 2012, 03:18:11 PM |
|
You can now send bitcoins via email: - An email containing the private key is sent to the desired email address.
This seems like a really bad idea. Email is a postcard. Writing private keys on postcards is asking for trouble. The problem is, of course, is setting the precedent. It's likely that it'll be perfectly safe for a while, until some dodgy admin gets the idea to scrape all emails for keys and mtgox codes. It's a shame, I know, you're only trying to make it easier to use bitcoins. Don't do it at the expense of security though. You have to find a breakpoint somewhere. What about all the banks that send password resets by email? While I agree that email is patently insecure and needs major help, I think this functionality is necessary for new users to help introduce them. Who knows, maybe some new users' coins WILL be stolen because of an email related insecurity - perhaps that would wake them up to the fact that there is more they could do to keep themselves secure.
|
|
|
|
realnowhereman
|
|
April 19, 2012, 03:26:23 PM |
|
You have to find a breakpoint somewhere. What about all the banks that send password resets by email? While I agree that email is patently insecure and needs major help, I think this functionality is necessary for new users to help introduce them. Who knows, maybe some new users' coins WILL be stolen because of an email related insecurity - perhaps that would wake them up to the fact that there is more they could do to keep themselves secure.
While I understand that some websites send passwords and identity confirmations by email; in flagrant lack of appreciation of the danger; I seriously doubt any reputable bank is doing so. Rather banks are moving more and more to these two-factor systems where they send you a key-generating device. The problem is considerably worse with bitcoins though; the process of scraping anything that looks like an address and stealing any funds on it could be completely automated very easily. Scraping every single format of password-resetting email and knowing every single bank account web site's log on method is considerably harder and you leave traces all over the bank's weblogs. Stealing bitcoins can be done close to anonymously if you've got that magic private key. You're quite right that there has to be some level of practicality considered. I'm simply arguing that distributing private bitcoins keys by email to newbies is setting the bar considerably lower than it should be if we're talking about money.
|
1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
|
|
|
realnowhereman
|
|
April 19, 2012, 03:27:48 PM |
|
I think that this step will be enough for making it secure - When "claimed" the key is swept into a new bitcoin address. Nope. This attack is done while the email is in transit. By the time the victim receives the email and activates the legitimate sweep; the attacker has already stolen the coins.
|
1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
|
|
|
mcorlett
Donator
Sr. Member
Offline
Activity: 308
Merit: 250
|
|
April 19, 2012, 03:30:30 PM |
|
What if you offered the choice of an optional security question?
If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
|
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4270
Merit: 1209
I support freedom of choice
|
|
April 19, 2012, 03:32:15 PM |
|
What if you offered the choice of an optional security question?
If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
Another good idea
|
|
|
|
piuk (OP)
|
|
April 19, 2012, 03:45:08 PM |
|
Nope. This attack is done while the email is in transit. By the time the victim receives the email and activates the legitimate sweep; the attacker has already stolen the coins.
If a malicious admin is reading your emails you've probably got more pressing security issues than loosing a few bitcent. The key could be encrypted with a shared password or pin but then you loose all convenience of a simple email. When talking about small amounts the benefits out way the risks in my opinion. What do you think of this: The email only contains the partial email address of the sender: you have been sent bitcoins from w_ll_t@_l___h__n.infoWhen claimed it asks what is the full email address of the sender and the user has to fill in the missing letters. e.g. in this case wallet@blockchain.info
|
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4270
Merit: 1209
I support freedom of choice
|
|
April 19, 2012, 04:26:11 PM |
|
There are some options, I will be good if you add all of them ( the sender should be able to make a choice ) 1) Nothing ( as it is now, it will be good if the email will have also a warning like this, example: "Be sure that you have your computer secured, because unclaimed bitcoins can be taken by viruses and bad people" ) 2) Hidden email address ( your actual proposal ) 3) The sender can write a "question" ( he know that only the receiver know the answer ) and the email will contain the private key encrypted with the hash of the "answer". Another good thing is the possibility to add a personal message, example: "here is a present for you!"
|
|
|
|
R-
Full Member
Offline
Activity: 238
Merit: 100
Pasta
|
|
April 19, 2012, 08:23:58 PM |
|
Hi Ben, While this isn't a crucial feature, it is one of the very neat aspects of your site (blockchain.info). We would love to see more cool statistics like this. Examples I came up with: - fastest block mined (in last 100,000 blocks)
- slowest block mined (in last 100,000 blocks)
- link to first block ever mined (genesis block)
- Day of highest total network hash rate since January 1 2012 (basically highest hash rate of year).
Robert What a great idea
|
|
|
|
|
piuk (OP)
|
|
April 21, 2012, 11:58:34 AM |
|
* Full iPhone app now available in the app store * Multibit can now import blockchain.info wallet files (using the latest git). Select your encrypted wallet.aes.json or unencrypted wallet.json Enter your password and second password then press the import private keys button. This is now the recommended way to restore wallet backups in case anything happens to blockchain.info (and the web interface isn't in your browsers cache). Thank you to Jim618 for merging the changes. Also thank you to the recent donators.
|
|
|
|
payb.tc
|
|
April 21, 2012, 12:20:29 PM |
|
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
|
|
|
|
piuk (OP)
|
|
April 21, 2012, 12:34:35 PM |
|
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
The usage has changed a bit recently. There is now few parameters: Mandatory: - "active" - addresses which you want included in the final balance. Optional: - "archived" - addresses which you want included the results calculations but don't want included in the final balance. - "offset" - skip the first n results - "filter" - show only transactions of a specific type: sent = 1, received = 2, moved = 3, escrow = 4; Separate multiple addresses with | e.g. http://blockchain.info/multiaddr?active=1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U&archived=14Dj368DZyFPDbSbERf53wcGLWefsZUamn
|
|
|
|
payb.tc
|
|
April 21, 2012, 12:41:05 PM |
|
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
The usage has changed a bit recently. There is now few parameters: Mandatory: - "active" - addresses which you want included in the final balance. Optional: - "archived" - addresses which you want included the results calculations but don't want included in the final balance. - "offset" - skip the first n results - "filter" - show only transactions of a specific type: sent = 1, received = 2, moved = 3, escrow = 4; Separate multiple addresses with | e.g. http://blockchain.info/multiaddr?active=1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U&archived=14Dj368DZyFPDbSbERf53wcGLWefsZUamn thanks! so, am i to assume that the limit on the number of addresses queried is related to the GET specification? or can one POST a larger list?
|
|
|
|
piuk (OP)
|
|
April 21, 2012, 12:43:08 PM |
|
so, am i to assume that the limit on the number of addresses queried is related to the GET specification?
400 is the limit for active addresses, i'd split it into multiple calls if you need more.
|
|
|
|
payb.tc
|
|
April 21, 2012, 12:44:43 PM |
|
so, am i to assume that the limit on the number of addresses queried is related to the GET specification?
400 is the limit for active addresses, i'd split it into multiple calls if you need more. okay, just curious... don't need anywhere near that many
|
|
|
|
payb.tc
|
|
April 21, 2012, 12:47:49 PM |
|
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount? "addresses":[ { "address":"1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a", "n_tx":3, "total_received":385000000, "total_sent":125000000, "final_balance":260000000 },
|
|
|
|
piuk (OP)
|
|
April 21, 2012, 01:03:01 PM |
|
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount?
It is 0 confirmations. Btw if total_received is the only thing you need your better off calling /q/getreceivedbyaddress with multiple addresses e.g. http://blockchain.info/q/getreceivedbyaddress/14Dj368DZyFPDbSbERf53wcGLWefsZUamn|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different.
|
|
|
|
payb.tc
|
|
April 21, 2012, 01:13:18 PM |
|
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount?
It is 0 confirmations. Btw if total_received is the only thing you need your better off calling /q/getreceivedbyaddress with multiple addresses e.g. http://blockchain.info/q/getreceivedbyaddress/14Dj368DZyFPDbSbERf53wcGLWefsZUamn|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different. thanks... but that url adds them all together into one amount. i need a list of total_received per address. did you modify/customize your bitcoind to be able to provide this info? if the standard one could do this i might not need to use a 3rd party api.
|
|
|
|
payb.tc
|
|
April 21, 2012, 01:30:56 PM |
|
Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different.
hmmm... i tried confirmation= confirmations= conf= minconf= and none worked for me. ...and i've run out of guesses
|
|
|
|
|