Quote from: OhShei8e on February 15, 2015, 08:06:28 PM

Man muss Transaktionen unterbinden und Buchungen rückgängig machen können. An einem System wie Bitcoin besteht ansonsten schlicht kein Bedarf.

Dann lasse mich mal ganz naiv fragen: Was würden wir eigentlich mit einem Bitcoin machen, bei dem die Überweisungen rückbuchbar wären? Angenommen, der Walletinhaber hat einen Revocation-Key, dann kann ein Betrüger doch eine Überweisung tätigen und dann seinen Key nutzen, um sich zu bereichern. Also zuerst Geld auf einen Exchange, dann Altcoin kaufen, Altcoin abziehen und Überweisung rückbuchen. Das geht innerhalb weniger Sekunden, wenn man es richtig anstellt.
Was wäre damit gewonnen? Ein gepwntes System kann den Revocation-Key sicher nicht nutzen, weil dafür müsste der Exchange erstmal im Besitz eines nichtkompromittierten Systems im Netzwerk sein. Andernfalls kann jegliches "Senden des Revocation-Keys" von den Angreifern unterbunden werden.

Angenommen, das Netzwerk entscheidet über die Rückbuchung. Dann muss der Betrüger nur dafür sorgen, dass die Latenzzeiten zu seinen Knoten vom Opfer aus möglichst gering sind. Dadurch verbindet sich das Opfer mit den vom Angreifer kontrollierten Knoten. Also ist auch eine solche Maßnahme relativ leicht auszuhebeln.

Anderenfalls würde kein vernünftiger Händler mehr Bitcoins annehmen, weil diese ja im wesentlichen zurückgeholt werden können.

Ein solches Feature macht schon beim oberflächlichen Betrachten mehr Probleme, als damit gelöst werden würden.

Hier sind die Exchanges in der Pflicht. Wenn nur Programmierdeppen nach dem "schnell-und-billig"-Prinzip eingestellt werden, braucht sich keiner zu wundern, dass das in die Hose geht. Da wird eine Komplexität in die sicherheitskritische Infrastruktur geladen, die nicht mehr auditierbar ist. An der Stelle mal den klassischen Bad-Smell genannt: Wenn mehr als zwei Sites verlinkt werden und dann noch jede Menge Java-, Javascript- und noch besser Flash- oder Silverlight-Müll nachgezogen wird, dann ist die Exchange das Vertrauen einfach nicht wert.

Sicherheit kann grundsätzlich nur durch einen Verzicht auf Komplexität gewonnen werden. Ansonsten arbeitet beweisbar die Statistik dank der damit verbundenen Bugs gegen die Sicherheit und für sämtliche Scriptkiddies.

Wer sowas also programmiert, sollte möglichst wenig Bibliotheken nutzen, möglichst wenige Dienste zusammen an einem isolierten Ort laufen haben, diese isolierten Orte gegeneinander Abschotten und zusätzlich extensiv den Code testen. Danach sollte der Code mehrere Security-Audits durchlaufen. Die Hardware sollte stark heterogen gewählt werden, damit Firmware-Bugs isolierbar bleiben und zu keinem Systemversagen führen.

Quote from: Christ0ph on February 15, 2015, 08:27:25 PM

Und noch mein Senf zur philosophischen Runde: wenn Handelsplattformen gehackt werden hat das doch nichts mit Bitcoin zu tun. Diese ganzen Hacks und Betrügereien schaden zwar dem Image und der Zukunft des Coins gewaltig. Aber es ist doch genausowenig die Aufgabe des BTC dies zu verhindern wie mein 5 Schein verhindern soll, dass mit ihm Gras gekauft wird.

Das ist genau der Punkt. Je mehr Features in Bitcoin selbst verbaut werden, desto wahrscheinlicher sind Bugs, die ein systematisches Versagen des zugrundeliegenden Clients verursachen können.