This is increasing the barrier to entry & risk for new merchants and bitcoin services, and making it harder to gain the trust of users.
Increasing barrier and risk? If you site is secured, you have no risk. If you site is not secure, YOU are causing the risk, no people probing your servers. Wait, it's the victims fault if s/he is attacked? OP is right, this does create a higher barrier for establishing a bitcoin business. It's like establishing a brick and mortar business in a violent neighborhood: you'll have to invest more in security, and even that might not be enough. Such costs and risks might be prohibitive to some. Even if they're not prohibitive, they'll have to be accounted for in the price of whatever product or service they sell. Incorrect. You cannot base the security of your ecommerce website on "trusting" everyone not to attack it even though it's vulnerable.
Sometimes you can. The local restaurant website where I often order my meals is quite lame. I know, for ex., that they don't hash passwords, it's stored as clear text. There are probably other security vulnerabilities. Judging by the web design, they probably had a very limited budget for building that site. If they had to have the level of security a site needs to have to exist safely in the bitcoin world, maybe they wouldn't even have a site at all, or their meals would be more expensive just to account for that. |
|
|
|
http://www1.folha.uol.com.br/mercado/1052730-cibercrime-atinge-32-das-empresas-no-pais-diz-pesquisa.shtmlO cibercrime foi a segunda modalidade de crime econômico mais incidente entre empresas em 2011 no país, apontou pesquisa bianual da PwC. Os delitos vão desde o roubo de dados de cartão de crédito até a violação da base de dados on-line de empresas.
Entre as 115 companhias ouvidas, 32% disseram ter sido vítimas de ataques digitais --em 2009, esse tipo de crime sequer era citado. O líder continua sendo o roubo de ativos, citado por 68% das empresas. Crimes digitais desbancaram corrupção e suborno.
Fernando Cevallos, gerente sênior de serviço forense da PwC, afirma que as cifras do comércio eletrônico brasileiro chamam a atenção de criminosos. "A tendência do fraudador é ver a vantagem que eles podem ter." O e-bit, consultoria que audita transações na web, previa movimentação de R$ 18,7 bilhões no ano passado, alta de 26% em relação a 2010.
Embora a incidência de cibercrimes seja alta, 51% dos ouvidos afirmam que suas empresas ainda não adotaram procedimentos de segurança ou implantaram métodos de proteção informal.
Apesar de a imagem arranhada ser a maior preocupação das vítimas (63%), as afetadas relatam prejuízos financeiros nada modestos: 8% perderam mais de US$ 5 milhões; 5% arcaram com rombo entre US$ 100 milhões e US$ 1 bilhão.
Só um pequeno alerta aos que pensam em desenvolver negócios relacionados a bitcoin: não estejam entre esses 51% que não adotam devidos procedimentos de segurança, lembrem-se que transferências bitcoins são irreversíveis!
|
|
|
|
I brought this semantic distinction in the first place because non-sciences like economics don't prove anything at all in the real world and only give degrees of certainty in repeatable scenarios. In this case they are basically applied statistics.
You're wrong there, sound economics can prove things, just like math. And sound economics shouldn't even use statistics as a basis for knowledge building, that's why I made the distinction about "empirical economics" (which I consider flawed, for the same reasons you point) and "aprioristic economics". The author(s) here are making highly speculative assertions about unprecedented situations without providing much base for them and taking a lot of dubious preconditions for granted. This level of discourse is very common in economics and sociology, even at academic levels. Just look at keynesianism.
Keynesianism is not sound economics, it's done empirically. |
|
|
|
However, deriving a result from a set of assumptions should not be confused with science.
That's how mathematics itself is done... you don't consider Mathematics to be a science? EDIT: Correcting myself, mathematics (and sound economics) derive results from a set of axioms, not assumptions, it is not the same thing. |
|
|
|
Also, if I read "the inevitability of collapse", I smell someone lacks attention.
hehe, yeah. Researches often desperately need to publish. |
|
|
|
I won't defend economics as an actual science. It isn't.
There are two ways of doing economics. Empirically, like physics, or aprioristically, like math. I agree that it is not scientific to do economics empirically, because you simply cannot isolate all the buzillions variables involved, nor repeat your experiments enough times to get good samples. They actually can't even experiment. But economics can be done like math, using logically sound constructions on top of axioms. This works much better and it is scientific. |
|
|
|
Quoting myself: People are already starting to use FPGAs, and maybe one day we'll even see ASICs.
Botnets won't have such specialized hardware. Ok, they have free electricity, but they are limited in size.
And by the way, in what concerns the bitcoin network, botnets are not a problem. It only becomes a problem if one single botnet is too large and manages to get >50%.
PS: I confess I did not read the paper so sorry if I'm saying something which is already addressed by it.
|
|
|
|
|
People are already starting to use FPGAs, and maybe one day we'll even see ASICs.
Botnets won't have such specialized hardware. Ok, they have free electricity, but they are limited in size.
And by the way, in what concerns the bitcoin network, botnets are not a problem. It only becomes a problem if one single botnet is too large and manages to get >50%.
PS: I confess I did not read the paper so sorry if I'm saying something which is already addressed by it.
|
|
|
|
Have you seen this? http://it.slashdot.org/story/12/02/14/2322213/998-security-for-real-world-public-keysThankfully to us Satoshi did not choose RSA for the private/public key algorithm of bitcoin! This is important nevertheless. Ok, 2 per thousand is statistically very low, but the fact that all these vulnerable keys can be gathered by any skilled enough attacker is quite troubling. I wonder how fast would the bitcoin development team be able to work out an algorithm migration if a similarly dangerous vulnerability were to be found on ECDSA or SHA-256 (these are the algorithms used for public/private key and hashing in bitcoin, respectively, right?) |
|
|
|
This is how most modern websites work. You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it. Take a deep breath, guys.
If plaintext passwords were stolen, either the attacker modified the code of the website to prevent pre-transmisssion hashing, or passwords were not salted before they were hashed, so the attackers just brute forced a rainbow table.
Uh, no. Maybe, just maybe, if someone was using SSL... which this site wasn't. But "most modern websites"? Utter BS. SSL wouldn't be of any help. Hashing in the client and authenticating the hash == storing passwords in clear text. To be honest, it is a little less bad than storing clear passwords because at least a leak wouldn't allow an attacker to screw users who use the same password on different sites. But in what concerns your server, it is the same. |
|
|
|
But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.
This is how most modern websites work. You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it. Take a deep breath, guys. If you're sending the hash to the server for authentication, hashing has no point: if your database leaks, anybody in possession of the leak can authenticate himself as any of your users. Remember the client is in control of whatever he sends to your server. He doesn't need to execute the javascript you send him, he can forge any requests as he pleases. The whole point of hashing a password instead of storing it in clear text is to prevent issues in case of a database leak. The hashing operation must be done in the server. |
|
|
|
What you're saying doesn't make much sense to me.
If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.
Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.
Well.. if you had a look at the javascript of bitscalper you would have spotted theyre actually using md5 hashed passwords.. so i guess he is not lieing about that.. I'm not disputing that. But it seems the exploit allowed the retrieval of clear text passwords. If they are not stored in clear text, how would that be possible? But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text. |
|
|
|
|
What you're saying doesn't make much sense to me.
If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.
Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.
|
|
|
|
It's quite amazing how this community seems to attract the worst security practices.
I'd say that unfortunately many software developers in general do not follow important security practices. The main difference with this community is that there is a considerable amount of people capable of exploiting such vulnerabilities. And, well, most of the time there's money involved, not only ordinary data. Congratulations for both chsx3 and theymos for the honest behavior. |
|
|
|
I presume the pools have a buffer of mature coins which they use to pay their miners. I don't have to wait; I can withdraw mature coins as soon as the pool finds a block.
So some pools "pay in advance". That would require them to have some "invested capital". And such money can be stolen, as we've seen here. In such event, unless the pool operator eats the loss himself, he will have to pass it to the miners. Honestly, I find it quite absurd accepting higher risks only for not having to wait one single day for maturation. But anyway... it's your money, do as you please. |
|
|
|
Before posting the question I decided to take a look in the blockchain.info... and even deepbit and Slush are attributing the generation coins to a single address, possibly to transfer them after the 120 blocks maturation period. Why? This is risky... Just send them immediately to the miners.
As a miner I would prefer that the pool sends the generated coins to itself and pays me in mature coins. That way I don't have to wait for 120 blocks before I can spend the coins. It doesn't make sense. You'll have to wait anyway. Either you wait with the money in your wallet, or you wait with it in the wallet of the pool operator. I find the former more secure. It's true that pool operators could also be eWallets, protecting the coins of miners that do not feel safe to do it themselves. But I assume miners to be fairly technical people who don' t really need an eWallet. |
|
|
|
I'd think the big ones might want to avoid a bunch of .000004 sends, since they have so many miners and such frequent blocks,
Well, if they are sending frequent transactions with all these .000004 spends, it would be the same, wouldn't it? Otherwise, if they don't want to create huge transactions so frequently, they can aggregate. At each block they pay 10% of their miners, for ex. The math might get complicated, but it should be possible. |
|
|
|
|
But why was the pool operator even keeping the miners reward? Couldn't he pay his miners immediately from the generation transaction, with a send to many?
...
Before posting the question I decided to take a look in the blockchain.info... and even deepbit and Slush are attributing the generation coins to a single address, possibly to transfer them after the 120 blocks maturation period. Why? This is risky... Just send them immediately to the miners.
|
|
|
|
But where's the incentive for a miner to do this? Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise. It can also be the other way around. Miners publicly offer to "support" transactions which contain a minimum amount of fee. I like where this is going. It seems a cheaper alternative to the "expensive green address" proposal I've seen before, and it is decentralized too. |
|
|
|
|
Pool operators can embed signatures in their blocks if they want.
It would be more complicated to organize such scheme on P2Pool though...
|
|
|
|
|
Show Posts
