Topic: For a website taking payments with bitcoins, better: IP or bitcoin addresses? (Read 17205 times)

The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent.  That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent.  Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.

A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem.  With resync, you could do about the same thing by sending all the money from one wallet to the other.  The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.

D҉ataWraith,

DNS is the simplest of protocols, all it does is to have a database, cache or forward to next DNS a request.

Basically goes like this:

you type: nslookup www.somesite.com

You computer goes to your resolv.conf or network config, according to your OS, pick your Nameserver and say:

«Hey! Dude! What the hell means www.somesite.com?»

The Nameserver looks it up if has it on its cache or database will reply: «Yo! Man! That's 123.123.123.123», if not will look it up and reply if find or will say «M'a man, there's no such a thing on the internet as far as I can tell!».

However someone may spoof the Nameserver and reply to your computer with a wrong address, which your computer will take for "the real deal".

The issue with DNSSEC is that, thus it's usable for root and authoritarian nameservers, it isn't for clients.
The difference?
Normally you must read on a ns lookup:
Reply without authority
www.somesite.com 123.123.123.123

This means the server that's replying to you knows where www.somesite.com is, but it's not the nameserver for such domain. - This is what your ISP NS's do normally.
On the other side you've the authority nameservers, means those whose the domain is registered to. Those update the root servers and yes, between those two, makes perfect sense update the root servers under a secure line to prevent some other nameserver as present itself as an authority to a domain it's not - which would spoof the address internet wide.

Now... clients does A LOT of DNS requests, it's normal that when you visit a page that page to have items stored somewhere else. For each "some where else" your computer does a DNS request... now just imagine if it has to negociate a certificate with the nameserver before.

As for attacks, it's something you must count on, but I do prefer to have users aware of the danger rather than go Fascist like imposing limitations to what they can do.
Security has to be moderate by the hazard, you probably would check your wallet every minute on a bus to see if it's still on your pocket if you carry like $1000, but you don't if you carry just 1 or 2 bucks. Likewise it would make the same sense to protect a computer bank-like if the user just has there a couple of pirate MP3.  

To get back to the original question, paying to a bitcoin addresses displayed on an https: webpage secured with a valid certificate is better.

When the bitcoin client supports secure connections to IP addresses, then paying to an IP address displayed on an https: webpage secured with a valid certificate will be just as good (security-wise, anyway).

Bitcoin doesn't try to solve the "am I paying who I THINK I'm paying problem" -- we need HTTPS and signed certificates and DNSSEC for that (or something similar).  Bitcoins are a small but really important piece of the payment puzzle...

How would the attacker get hold of a valid certificate that claims it's for www.somewebsite.com without actually controlling said domain?


Not necessarily. StartCom, for example, is recognized as a valid CA by almost anyone (Opera being the exception). CACert ist also included in popular Linux distributions (e.g. Debian).


Ehm. DNSSEC _is_ a standard, and the root servers and many TLDs are already using it, although it will only become fully functional later this year. It's true that it is not as efficient as it could be (and was rightly criticized thus by people like Daniel J. Bernstein), but with .com, .net and .org adopting it within the next year or two, I'd pretty much say it's a done deal.


Well, I was working with the premise of IP payment, because that's what you brought up in the snippet I replied to with that paragraph. Of course you can just use a Bitcoin address (unless the payee wants you to pay DCC-style...)


^^

The thing with security is that you have to be aware of what _could_ happen. I don't walk around with 1000$ in my wallet, precisely because it could be stolen, for example. If Bitcoin becomes an accepted currency, attacks *will* happen -- just think of all the phishing that's going on with Paypal and normal banks. If there's a way, it will be exploited by criminals.

Sure does, that's what a certificate does: Hey! You're on www.somewebsite.com and the data is crypted.
The question is that, imagine somewebsite is meant to be at 123.123.123.123 and someone else spoofed DNS for it to resolve to 123.123.123.124, then your browser will believe it is at www.somewebsite.com - even if it's phishing.
And for free certificates, they might include the security they want, but no browser recognizes their root CA's, so it makes them as worthable (and will raise the very same alerts) a self-signed certificate.

DNSSEC is yet another piece of junk. That probably would never come to be nothing but a project. Issues of practical life, negociating crypt algorithms reduces performance and DNS is a really heavy duty service. So, if someone tries to implement DNSSEC as a standard, internet would probably become as slow as Tor is.

And if someone doesn't want the one he's paying to to know his address, probably the person that's receiving the payment doesn't want to show his address either. Therefore they simply DON'T use DCC Pay, but P2P Pay. Easy... as long as both options are there.

I'm up to choices not to paranoia. Paranoia in security isn't of any value add, paranoia is just that... paranoia. Reduces life quality, grants nothing and prevents people from live.
Yes, someone may steal your data, as someone may steal your wallet on the bus with the very same outcome. There're some security elementals, but you can't keep looking over your shoulder (specially because you probably will miss to see the electrical post in front of you). 

I'm by no means an expert on this, but I think even a free certificate includes a "this is for website www.example.com"-field, and you can only get a certificate if you actually control that domain (can receive email sent to the domain), so I don't think forging that is trivial. Firefox, for example, explicitly pops up a warning if a certificate is for a domain other than the expected one.

The remaining weak link then is DNS, but while possible, it is non-trivial to forge that, especially when you're watching the destination-page, and can't know who is going to want to visit it beforehand. Also, DNSSEC is slowly becoming the norm, so that possibility also goes out of the window within a few years.

The reason why I bring up TOR is that bitcoin complements it very well. TOR preserves anonymity, and bitcoin allows for anonymous transactions.


Suppose someone doesn't want to know the payee who he/she is? Without TOR the IP address is revealed, which, at the very least allows the other party to know the approximate geographical location.

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 .onion then you wouldn't need SSL, because inner Tor data is already crypted.

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.

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. 

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).

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.

If authentication is handled perfectly, this is nearly impossible.


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?

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.

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.

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).

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.

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

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.

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. 

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!)