For a website taking payments with bitcoins, better: IP or bitcoin addresses?

[Minsc]

For a website taking payments with bitcoins, which is better: taking payments through IP solely or using tons of bitcoin addresses that you have to reuse and reuse?

And why?

[1713282638]

1713282638

[1713282638]

1713282638

[dwdollar]

Right now, Bitcoin Addresses are the only option if you want automation.  If you're only taking donations, or only handling manual transactions, IP Addresses might be better suited.  That way they can send you comments or messages about their account info.

[dsg]

Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.

[Xunie]

Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.

Isn't that "unsafe"?
Say I am an exit node listening for bitcoin transactions and grab them?
Or is everything public/private key encrypted?<sup>[1]

[1]Which is my guess.</sup>

[Xunie]

Actually no, transfering coins via IP address isn't encrypted. When you transfer coins to an IP, the recipient creates a new address just for that transaction and tells you to transfer coins to that address. A malicious exit node could sniff all Bitcoin traffic and intercept those transactions easily.

So for everyone: DO NOT USE IP ADDRESSES AS DESTINATIONS, ALWAYS USE BITCOIN ADDRESSES.

I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.

[satoshi]

I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.

That's a good idea.  At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

[Xunie]

I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.

That's a good idea.  At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

Note: I also suggest we show the warning everytime and do not give the user an option to disable that.
(Like a checkbox that is marked "Show this warning everytime I use a proxy and send an IP transaction.".
That'd be bad in my opinion, a user would disable it and forget about the proxy he's connecting through!)

[SirArthur]

Actually no, transfering coins via IP address isn't encrypted. When you transfer coins to an IP, the recipient creates a new address just for that transaction and tells you to transfer coins to that address. A malicious exit node could sniff all Bitcoin traffic and intercept those transactions easily.

So for everyone: DO NOT USE IP ADDRESSES AS DESTINATIONS, ALWAYS USE BITCOIN ADDRESSES.

That's not "for everyone", but for those up to buy or sell some stuff more... strange.
I believe the core aim of BC is to be an easy to carry non-centralized currency, anonimity is a surplus not a mandatory field. Otherwise we would rather call it TorPay.
So, unless the transaction is for the a new pedo movie, some crack shipment or some stuff alike, there's no reason to use Tor, and therefore no exit nodes and no proxies. In the end trimming your advice: If you're up to make a "non conventional" payment over Tor, use the destination's BC Address, if you're buying or selling something normal, use IP or BC address. 

Then we've the eternal ballance: Usability x Security. Too much security = too few usability (the most secure computer in the planet is... anyone since it's switched off) and too much usability = too few security. Ballance is better than paranoia. 

[theymos]

It's not just an issue with proxies. Since there's no authentication, any "man in the middle" can intercept your BitCoin transfer, including your ISP and other people on your wireless connection. It's like logging into your bank's website without HTTPS.

BitCoin should use an authentication method like SSH: the receiver signs the BitCoin address and other info with a permanent public key, the hash of the public key is displayed to the sender before any transfer, and the receiver makes this hash known through other trusted channels.

[Xunie]

It's like logging into your bank's website without HTTPS.

I agree, this is a pretty large security hole.
We need a bug tracker for this stuff.

[SirArthur]

It's not just an issue with proxies. Since there's no authentication, any "man in the middle" can intercept your BitCoin transfer, including your ISP and other people on your wireless connection. It's like logging into your bank's website without HTTPS.

BitCoin should use an authentication method like SSH: the receiver signs the BitCoin address and other info with a permanent public key, the hash of the public key is displayed to the sender before any transfer, and the receiver makes this hash known through other trusted channels.

Sure, encryption would be a good feature, TLS for an instance.
About ISP's, and mainstream internet, if you don't trust them you rather not make also a phone call anymore.
But isn't quite "like login to a bank without HTTPS", one can intercept a single BC transfer but doesn't get the hability to start further bitcoin transfers on hisown; which would happen if it was your bank login instead.

Still there's room for both: DCC and Address transfers. Such relies more on "who and why" are you paying than the payment itself.

[Gavin Andresen]

It's not just an issue with proxies. Since there's no authentication, any "man in the middle" can intercept your BitCoin transfer, including your ISP and other people on your wireless connection. It's like logging into your bank's website without HTTPS.

I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

All transactions are broadcast to all Bitcoin generating nodes, anyway, and the transactions are impossible to alter or forge (because they're digitally signed).

A man-in-the-middle could drop the transaction, but SSL doesn't fix that-- if they're relaying SSL traffic they could drop your SSL-encrypted transaction, too.

There are good non-security-related reasons for encrypting Bitcoin transaction traffic, though (makes it harder for governments/ISPs to do deep packet inspection to selectively drop Bitcoin traffic, for example).

[theymos]

I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

When sending to an IP address, BitCoin contacts the IP address without any authentication/encryption and requests a new BitCoin address, which is also sent back in plaintext. You then send the BitCoins to that address in the normal way. A man in the middle can intercept this request and send back their BitCoin address. You will then securely transfer BitCoins to the wrong person.

[SirArthur]

I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

When sending to an IP address, BitCoin contacts the IP address without any authentication/encryption and requests a new BitCoin address, which is also sent back in plaintext. You then send the BitCoins to that address in the normal way. A man in the middle can intercept this request and send back their BitCoin address. You will then securely transfer BitCoins to the wrong person.

But a man in the middle can also intercept the key negociation for OpenSSL and decrypt the packets.
If BC goes as payment standard other attacks may come along, as forging hashes.

This round about for the eternal question: Does it worth it?
Like Windows and Linux, none is safer than the other, Windows has registry, in time it has autoexec.bat, but so does Linux have .bashrc, inetd, xined and several ways to put "crap on boot", to not mention Linux is OpenSource and this may be a security hole because Open Source doesn't mean "Open only for the right people", but "Open for the wrong as well". Still the number of virus and malaware for Windows is astronomical compared with those available for Linux. Why? Simple... Windows has the biggest market share. If it happens to be the other way around than it would be more profitable to make crap for Linux than Windows things would go the otherway around.

[theymos]

But a man in the middle can also intercept the key negociation for OpenSSL and decrypt the packets.

If authentication is handled perfectly, this is nearly impossible.

forging hashes

This is even more difficult than breaking TLS. If you don't trust cryptography, why are you using BitCoin? The authentication I'm talking about is extremely similar to the core technologies that make BitCoin work.

Right now it's trivially easy for your ISP to steal all BitCoins sent to an IP address. It's possible (and probably not too difficult) to make this very non-trivial. Why on Earth would we not do this?

[SirArthur]

theymos:

Like I said; if it worth it.

There're some random vars to add too, as to know when someone will send something.
But, yes, TLS would be nice, why make things easier to steal when we can do it a bit harder? TLS adds some good security without cut too much usability.

I wouldn't care for ISP's anyway, if you mistrust them that much as I said before, you rather not make a phone call anymore on your life, taken telecom companies can easily tap it. But for those using proxies, some user-run proxies, yes, authenticate over plain text for those is a russian roulette.

[Gavin Andresen]

I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

When sending to an IP address, BitCoin contacts the IP address without any authentication/encryption and requests a new BitCoin address, which is also sent back in plaintext. You then send the BitCoins to that address in the normal way. A man in the middle can intercept this request and send back their BitCoin address. You will then securely transfer BitCoins to the wrong person.

Ahh, right, I see; I hadn't thought through the mechanism of the pay-via-IP-address functionality.

That brings up another possible man-in-the-middle attack for HTTP connections:  if you see a Bitcoin address on a non-secure web page, you can't be sure that you're seeing the correct address (a man-in-the-middle might have replaced it with THEIR Bitcoin address).  And ditto for sending your Bitcoin address to somebody to request payment (e.g. send it via email or in your forum signature and it might get replaced before being displayed to people who want to send you money).

[SirArthur]

That brings up another possible man-in-the-middle attack for HTTP connections:  if you see a Bitcoin address on a non-secure web page, you can't be sure that you're seeing the correct address (a man-in-the-middle might have replaced it with THEIR Bitcoin address).  And ditto for sending your Bitcoin address to somebody to request payment (e.g. send it via email or in your forum signature and it might get replaced before being displayed to people who want to send you money).

And if you leave your house you can be hit by a car. Oh! Wait! If you remain at home a plane may crash over your roof. 

MiM attacks that can perform defacing can perform it on all the ways - with or without SSL. Like spoof your DNS and make your browser believe to be seeing the "right page".
The only way to be 100% secure on informatics is to be offline with the computer switched off from power. As long as it is on, there're a few "thousands" of possibilities and... sh*t happens. 

[D҉ataWraith]

MiM attacks that can perform defacing can perform it on all the ways - with or without SSL. Like spoof your DNS and make your browser believe to be seeing the "right page".

Actually, gavinandresen raised a very good point here. For example, when browsing over TOR, a malicious exit node could indeed replace bitcoin addresses very easily. Contrary to what you said, SSL would fix the issues raised, because when the content is hidden, the attacker can't even know whether there is a bitcoin address on the requested page at all, much less replace it. Spoofing DNS would also be detected because the certificate wouldn't be valid (unless the attacker managed to spoof an SSL certificate, which is still very very difficult).

The thing to note here, though, is that the bitcoin client itself can't do anything about all of this, only the websites that use Bitcoin can -- and, for example, bitcoinmarket and bitcoinexchange already do.

[SirArthur]

Leave Tor aside, that would be more "Man in the Center" rather than "Man in the Middle".  
As for the attacks on websites with BC addresses, you may deface them, and you may spoof even without the server's Private Key. Normally people don't look to the CA, so as long as the CA is recognized it will ring no bells - and within this "world", specially for Tor users, Verisign Certificates aren't the normal thing, but CACert and other free services alike (means also many users are already used to press "Continue" on invalid certificate flags).

If by anymeans you got the server's private key then it doesn't make no difference, for your browser that Certificate is signing that address and, as far as DNS can tell, that server is there.

Edit:
To not mention the obvious: If you know the destination's IP Address why on Hell you would need to use Tor to pay?? And if the address would be something like <some unreadable hash>.onion then you wouldn't need SSL, because inner Tor data is already crypted.