Topic: Eine Idee, die es wert wäre zu realisieren. (Read 3340 times)

Na das ist aber wohl nicht immer so.

Ich hab jetzt nicht den ganzen Thread gelesen, aber weiss jetzt irgendjemand was die Idee ist?
Ausser das sie genial ist..

Es gibt da einen guten Thread im Bitcointalk-Forum (find ihn grad nicht) in dem steht das wenn man die Idee nicht veröffentlichen will weil man angst hat das andere sie stehlen könnten und das ganze besser machen könnten man sowieso der Falsche für die Umsetzung ist. Auch wenn du dann ein paar Monate vorsprung hättest, bringt dir nicht viel wenns die anderen professioneller machen.

Ok, stimmt.



Das ist nicht mein Problem, dann willst du nicht dabei sein. Redmine ist eine Web-Software fürs Projektmanagement, die mir hier jemand empfohlen hat. Hatte Probleme bei der Installation von Ruby on Rails. Da fehlte wohl was als ich die Software ausführen wollte... deswegen dieser Drittservice.
Ich melde mich fast täglich bei irgendwelchen Seiten an.

Weil die Komponenten und Sprachwahl praktisch nie ausschlaggebend für die Sicherheit des Systems ist. Es sind immer Architekturprobleme, Designprobleme und einfache Implementierungfehler. Bei letzterem ist der Fehler Nummer 1 etwas selber zu machen, was die qualitativ ordentliche Standardlösung schon lange gelöst hat. Bei jedem zweiten Problem stolpere ich über Reste des NIH (Not Invented Here) Syndrom, sei es bei Protokollen, Cryptolösungen oder Standardbibliotheken.


Security by Obscurity ist keine Sicherheit. Wenn der Einbrecher an den Sicherheitsmechanismen vorbeigekommen ist, muss man damit rechnen, dass er nimmt was er bekommt. Ein bischen Obscurity durch den Compiler ist dann kaum noch relevant. Ziel muss sein, dass ein Einbrecher nicht unbemerkt ins System kommt. Wenn erst mal ein Enbruch im System war - vor allem wenn dann auch noch unbekannt ist ob es eine Priviledge Escalation gab - ist das System sowieso kompromitiert. Dann kann bis zum SMM Handler jeder mögliche Dreck im System stecken und alle Daten sind als kontaminiert zu betrachten. Die einzige Reaktion darauf kann sein, das System zu löschen und alle Schlüssel zu ersetzen. Und zwar ohne Ausnahme ALLE!

Ein compilierte Code ändert nichts daran an der notwendigen Reaktion. Sich darauf zu verlassen, dass der Angreifer zu blöd war compilierten Code zu verstehn oder zu infiltrieren ist blauäugig.

Abschliessend zu diesem Thema von meiner Seite:

@amunet
Nur zum Verständnis, mir geht es hier überhaupt nicht darum dir Vorzuschreiben wie du dein Projekt
Entwerfen sollst. Im Gegenteil, ich finde es gut Ideen zu haben und vor allem diese dann auch
umzusetzen. Wenn schon brauchbarer Code vorliegt verwerte diesen und starte dein Projekt.
Wenn es gut läuft, kanst du immmer noch Entscheiden, ob zusätzliche Sicherheit nötig ist.
Zumindest hast du jetzt schon ein paar Ideen was man machen könnte. Verzichte auf zu komplexe
Layer-Schichtung, da jeder Layer die Anzahl möglicher Exploits auf deinem Applikations-Stack
multipliziert. Keep it simple and fast. Wo weniger dran ist, kann auch weniger kaputt gehen ;-)

@mezzomix


Weiss ich und du ja scheinbar auch, insofern verwundert mich deine Einstellung *die anderen machen es ja auch so*.


Das muss DU mir nun mal Erklären, vielleicht mit folgender Analogie.
Welchen Vorteil hast es einem Einbrecher (Hacker) nachdem er die Sicherheitsvorkehrungen deines Hauses (Server)
überwunden hat, den kompletten Grundriss des Hauses und damit die Wege und Lage deiner Wertsachen (DB/Wallet)
offen auf den Küchentisch zu legen (Script), anstatt diesen in einem versteckten Safe zu Deponieren (Kompillat)?
Ganz besonders, wenn wir davon ausgehen würden, dass der Einbrecher ohne Grundriss nur das Bild deiner
freundlichen Schwiegermutter in Öl über dem Kamin mitnehmen könnte, anstatt deiner echten Wertsachen? 

Ich meine, man sollte sich nicht so auf diese Scripte versteifen. Ihr würdest euch wundern was auf Börsensystemen und professionellen Transaktionssystemen im Backend läuft. Es gibt einen Unterschied zwischen Interface und Implementierung. Wenn ich eine Anfrage X an einen Service sende und er Antwortet mit einer Aktion Y, dann ist es für die Sicherheit aus Architektursicht unerheblich ob dahinter ein compiliertes Programm, ein Script oder ein Angestellter sitzt. Aus der Implementierungssicht könnte (!= muss) das Script von der Security her sogar die bessere Lösung sein als ein compiliertes Programm oder ein Angestellter.

Wer Kontrolle über den Server der "sende x BTC an Y" an den "Unterschreiber" schickt hat, der kann auch die Einmalpasswörter auslesen und ein korrektes Passwort mitsenden.

Irgendwann muss so ein Teil in deinem System existieren, wenn es automatisch ablaufen soll. Da ich mich sicher nicht auf irgendwelchen australischen Cloudservices für eine 7 kB Textdatei anmelde, wird es wohl dabei bleiben, dass mir deine Idee ein Mysterium ist.

Diesen Angriffsvektor könnte man mit einer Authentifikation durch eine Einmal-Passwort-Liste beseitigen.

Ich finde die Diskussion trägt bereits zu dem Projekt bei.


Ich verweise nochmal auf das Update im Anfangspost, da ich die Idee auf Englisch genauer erläuterte und dieses Dokument nach einer Einladung lesbar ist.

Irgendwo sitzt in dem System (sofern es automatisiert ist) ein kleines Kästchen, das einfach nur "3 BTC an 12345abc" bekommt und das dann unterschriebt und absendet. Ob jetzt jemand das Kästchen oder die Stelle kompromittiert, die diese Anweisungen gibt, ist wohl egal. Klar kann man z.B. den Riegel manuell vorschieben (z.B. "alles über 1 BTC in 24 Stunden erstmal NICHT unterschreiben, das schau ich mir lieber erstmal selber an!"), aber solange das automatisch laufen soll, hast du einfach 0 Chance.

Irgendwie ist das Ganze hier aber ziemlich spezifisch und Off-Topic geworden.

Da es zu der Idee anscheinend ja nix neues/genaueres gibt und sie erst enthüllt werden soll, wenn da auch wirklich was dazu existiert fürchte ich, dass es ab hier eh nur bergab gehen kann. Viel Erfolg an den TE, vielleicht schafft man es ja wirklich auch mit solchen vagen Umschreibungen schon mal Leute zu interessieren, die das auch machen?

Das ist korrekt. Ich bin eine Transe, aber lass mich doch gerne mit "sie"/Frau anreden. Doch relevant ist das nicht gerade hier.
Ich bin nur eine Person, manchmal zwiespältig, also vielleicht doch mehrere? lol.


Ja ein zweites inputs.io sollte nicht passieren


Die Dateien mit Zugangsdaten als auch die Scripte könnte man verschlüsseln und das zugehörige Passphrase auf mehrere Dateien (teilweise ebenso verschlüsselt) verteilen bzw. so dass ein Angreifer dies nicht ohne großen Aufwand heraus findet.


Ja gut. Hm. Dafür bräuchte man eine etwas andere Art von Programmierer als einfach fürs Web.
Wäre allerdings schon weitaus solider als Interpreter.. wenn sich genug Mitwirkende dazu finden, würde ich das durchaus vorziehen. Zumindest für die sicherheitsrelevanten Teile.





Ja moment.. Man kann doch von Webserver zu Server 1 eine Auszahlungsanweisung samt Bitcoin Adresse schicken usw. - Dann leitet Server 1 diese Anweisung an Server 2 weiter - hier hat es mit dem Webserver nichts mehr zu tun also steht auch in keinem Script auf dem Webserver irgendwelche Logik dazu. Und so weiter.

Transaktionsserver können ohne Event NIX machen. Der originäre Trigger kommt IMMER aus dem Netz.
Handlungsisolation gibt es nicht. Oder woher hat der TAS die Information und Daten eine Auszahlung zu veranlassen?
Maschinelle Intuition? 

Du kannst es Drehen wie du willst und Layer über Layer einsetzen um die gefühlte Sicherheit
zu verbessern aber sobald die den Trigger auslösende Schnittstelle (hier Das Web) offen ist
(Scripts) hast du mit allen nachfolgenden Sicherheitsmaßnahmen zwangsläufig verloren.
Ist doch auch klar, wenn der Auszahlauslöser im Web logischerweise bis auf deinen TAS einwirken
muss um eine Auszahlung zu veranlassen. Wenn diese Auszahllogik offen liegt, ist das System Kaputt,
egal wieviel hinten dranhängt.
Und genau darum gehts, diese Logik als offenes Script auf dem Server zu *Lagern* ist das Problem.

ps: Es sei denn, du kannst dich an den eigenen Haaren aus dem Brunnen ziehen.

Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.

Wird schon gemacht, grössere Auszahlungen, die aus dem Cold-Wallet kommen werden nur in einem zugelassenen, vom CW-Server definierten Zeitfenster
ausgeführt. Anfragen ausserhalb des Zeitfensters werden vom System verworfen bzw. gar nicht erst beantwortet, da der Port
geschlossen bleibt.

Da kommst du nicht drumherum, egal wieviel Layer du dazwischen Schaltest. Letztendlich verarbeitest du Anfragen aus dem Web und
damit hast du eine bestehende Reaction-Chain.


Falsch, wie oben beschrieben. Genau das macht den Unterschied. Bei Script bist du deine Coins los. Kompiliert nicht.

Weiss gar nicht ob ich das schon irgendwo geschrieben hatte: Zumindest bei einem neu eingeführten System würde ich mindestens in der Anfangszeit die Auszahlungsfunktion des System mit nachgeschalteter manueller Kontrolle laufen lassen.

Zwischen Transaktionsserver und einem späteren Auszahlungsserver lässt sich dann mit den entsprechenden Erfahrungswerten auch wunderbar ein Test schalten, der typische Auszahlungsmuster überwacht und die Auszahlungsfunktion trennt bzw. nur noch manuelle Prüfung zulässt, sobald eine Abeichung vom bekannten Muster auftritt.

Nebenbei wäre ein Penetration Test auf einem parallel dazu laufenden identichen Dummy System nicht falsch.

Geht mir ja gar nicht ums Geschlecht, sondern eher ob "Sie" schon Mehrere sind.

Irgendwer ist immer root, ohne Vertrauen geht gar nichts wenn du nicht Bitcoins verwendest sondern IOUs (also Schuldversprechen). Sobald jemand in deinen Dienst was einzahlt, hat derjenige keine Bitcoins, nur mehr dein Verprechen, dass du sie irgendwann irgendwie zurückzahlst.

Einzahlungen kann man ganz einfach in der Blockchain überprüfen, dazu muss man nur die benutzten Adressen kennen, sonst gar nix.
Auszahlungen brauchen auch quasi keinen Netzwerktraffic (ein paar 100 Bytes für die Transaktion ins Bitcoinnetz) - aber irgendwo muss eine Maschine stehen, die Zugriff auf die Keys zu den Einzahlungsadressen hat. Quasi jeder Hack wurde dadurch ermöglicht, dass jemand Zugriff auf den Server erlangt hatte, der Auszahlungen ermöglicht.

Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

Vieleicht "Es"? SCNR 

Möchtest du nicht den Titel deines Threads auf einen seriöser klingenden Titel ändern.
Würde deutlich mehr Aufmerksamkeit darauf ziehen, denn so schreckt es potentielle Mitstreiter ab, bevor sie den Thread öffnen.

zB. "Eine Idee, die es wert wäre zu realisieren." oder "Habe eine Idee mit hohem Potential, suche Mitstreiter." etc.

P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Für einen Transaktionsserver bei dem richtig Geld im Spiel ist, kann ich mich mit dem Wohnzimmer irgendwie nicht so recht anfreunden. Ein überwachtest Rechenzentrum/Bürogebäude wäre da schon schöner - vor allem wenn die Zugangskontrolle mit der Notabschaltung des Systems gekoppelt wird.


Ein unbemerkter root Access ist auch für compilierten Code fatal. Wird das eindringen bemerkt ist sowieso speicherlöschen und Notabschaltung angesagt.

Bevor ich das gesammte System selber codiere und was weiss ich wie viele Fehler einbaue, setze ich hier lieber auf Standardlösungen kombiniert mit angepassten Überwachungs- und Sicherungsmechanismen.


CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben. Mit welcher Technik die Schnittstelle betrieben wird (Scriptsprache, kompilierter Code) halte ich nicht für ausschlaggebend.

Ein bischen sorge macht mir bei diesen Systemen das Betriebssystem. Auch hier ist eine eigene Implementierung meistens nicht realistisch. Wenn schon der Layer 2 Treiber Lücken hat, ist die restliche Absicherung auf Sand gebaut. In kritischen Projekten setzen wir dafür externe Überwachung ein. Macht die Sache aber nicht kostengünstiger.