Blackbot Posted February 17, 2010 Report Share Posted February 17, 2010 Im Prinzip ist es das gleiche, allerdings kann man ein Passwort ergaunern (z.B. indem man mal das Kommlink eines unvorsichtigen Mitarbeiters durchwühlt, der es irgendwo gespeichert hat) - eine biometrische Authorisation nicht so leicht. Link to comment Share on other sites More sharing options...
HarryKane Posted February 18, 2010 Author Report Share Posted February 18, 2010 Im Prinzip ist es das gleiche, [...]D.h. jetzt? Kann ich einen Account der eine biometrische Eingabe erfordert genauso leicht hacken wie einen ohne? ... das fänd ich seltsam ... Link to comment Share on other sites More sharing options...
Tycho Posted February 18, 2010 Report Share Posted February 18, 2010 Jo, es macht keinen Unterschied welche Sicherung du nutzt, alles wir gleich gehackt. cyaTycho Link to comment Share on other sites More sharing options...
Fastjack Posted February 18, 2010 Report Share Posted February 18, 2010 Regeltechnisch ist es ein und dasselbe (das Passwort könnte ja auch aus 256 altpersischen Hirogyphen bestehen, während die biometrische Eingabe nen doofer Fingerabdruck ist *g*)... RPG-Technisch kann man da natürlich Hürden einbauen, wenn es daran geht an den Passcode zu kommen (das Passwort auf nem Zettel unter der Tastatur ist einfacher zu klauen als der Daumen)... Link to comment Share on other sites More sharing options...
Tycho Posted February 18, 2010 Report Share Posted February 18, 2010 Naja, da nimmste den Plastikbecher vom Mittag aus der Kantine oder sowas. Imho ist es bei einer unvorsichtigen Person wohl recht leicht an Biometriedaten zu kommen. Fingerabdrücke hinterlässt man auf einer menge oberflächen.Gendaten praktisch überall, Retinascans dürften durch die Verbreitung von Cyberaugen einfach keine verwendung mehr findenBlut ist recht schwer unauffällig zu beschaffenSprachmuster sollten mit dem ganzen Schnickschnak wie Selektive Soundfilter, Audioverbesserung usw. auch nicht so problematisch seinGesichtsmuster kannste ja schon mit einer Knopfkamera und nen Programm anfertigen von daher, wenn ich weiß was ich brauche, kommt man eigentlich relativ einfach ran bei Biometriedaten. Der Punkt beim hacken ist einfach der, ich hab ja in keinem der Falle einen gültigen Zugang, daher ist es auch egal wie diese aussieht (ob Passwort, Web of Trust, Biometrie, o.ä.), ich umgehe ja beim Hacken diese Abfrage, daher ist es auch nicht schwerer mit Biometrie. cyaTycho Link to comment Share on other sites More sharing options...
HarryKane Posted February 18, 2010 Author Report Share Posted February 18, 2010 Der Punkt beim hacken ist einfach der, ich hab ja in keinem der Falle einen gültigen Zugang, daher ist es auch egal wie diese aussieht (ob Passwort, Web of Trust, Biometrie, o.ä.), ich umgehe ja beim Hacken diese Abfrage, daher ist es auch nicht schwerer mit Biometrie. Ok, das Argument überzeugt mich in gewisser Weise. Link to comment Share on other sites More sharing options...
tamanous Posted October 16, 2012 Report Share Posted October 16, 2012 (edited) ich wärme das jetzt doch nochmal auf ... weitere varianten: - dem verschlüsselnden Verschlüsselungsprogramm den Befehl (erfolgreich) vortäuschen z.B. die Verschlüsselung zu beenden oder das Passwort mitzuteilen.- das verschlüsselnde Verschlüsselungsprogramm zum Absturtz bringen (angreifen) oder es beenden (erfordert Zugriffsrecht(oder dessen Vortäuschung)) ---- übrigens: - wenn ich das regelwerk extrem wörtlich lese,en unwired, p. 65, "the access log"Every node keeps an access log as part of its routine operation. The access log is a file that stores the record of everything done by, in, or to that node. dann kann das access log nicht auf einen zweiten Knoten(!), geschweige denn Host/Server verschoben werden. Ja, ich weiß, dass man dies heutzutage einstweilen aber so macht. - wenn das Verschlüsseln der Daten X Zeit dauert, dann kann das access log nicht in Y Zeit (bei Y < X) aktualisiert werden, da die Daten/Informationen auch erst noch verschlüsselt werden müsssen. Der Hacker hat also [ Verschlüsselungszeit + access log delay time ] Zeit zum Hacken des access logs.-- hieraus folgt: starke Verschlüsselung ergibt für access logs nur sehr begrenzt Sinn. Edited October 16, 2012 by tamanous Link to comment Share on other sites More sharing options...
Ultra Violet Posted October 16, 2012 Report Share Posted October 16, 2012 Es geht nicht darum das orginale Log auf dem zweiten Node zu haben, sondern um eine Kopie des Orginals das dann abgeglichen wird und bei Manipulationshinweisen Alarm schlägt. Link to comment Share on other sites More sharing options...
tamanous Posted October 16, 2012 Report Share Posted October 16, 2012 (edited) Danke dir. Zeig mir bitte meinen Denkfehler, sofern er da ist. Angenommen der Traffic geht ohne Zeitverlust, dann ok. Bleibt trotzdem die Zeit zum Verschlüsseln. - offrules - schonmal versucht eine Datei zu kopieren während sie verschlüsselt wird? Das Ergebnis ist eine bunte Sammlung aus Nullen und Einsen, das extrem aufwändiger Bearbeitung bedarf.Man müsste einen Zeitpunkt abpassen, an dem die Datei nicht verändert wird. --"aber ich kann ja partiell kopieren". Dann musst du auch partiell verschlüsseln. Nein, bei der Verschlüsselung wird die gesamte Datei(bzw der Container) (um-)geschrieben (siehe unwired).Da das access log aber ständig verändert wird, ist das Anlegen einer Kopie bei permanent laufender Verschlüsselung ... schwer.Ferner: Auch die Spinne muss [ Verschlüsselungszeit ] warten bis im access log ein Eintrag erscheint, bemerkt also auch erst viel zu spät, wenn/dass etwas passiert. Edited October 16, 2012 by tamanous Link to comment Share on other sites More sharing options...
Ultra Violet Posted October 16, 2012 Report Share Posted October 16, 2012 Bei der Log-Editierung seitens des Hackers geht es eigentlich nicht um die aktuellen Aktionen/Hacks, viel mehr ist es dazu gedacht am Ende seiner Hacks seine Spuren zu verwischen, d.h. seine IDs und Handlungen usw. sprich die Beweisspuren seiner Verbrechen zu vernichten.Daher ist es vielleicht besser wie Forensik zu sehen um auf die Spur des Hackers zu kommen. Und daher spielt die Zeit kaum eine Rolle. Desweiteren kann die Verschlüsselung sehr schnell stattfinden und das Schicken bzw. Downloaden und Aktualisieren/Prüfen der Log-Datei ist auch ein sehr schneller und einfacher Prozess. Das diese nicht parallel stattfinden ist wohl nur logisch, doch kann man davon ausgehen das die Verschlüsselung für den zweiten Node (wo die Kopie landet) keine Rolle spielt, entweder ist er mit in die Verschlüsselung integriert oder bekommt den Schlüssel über einen anderen Weg. Im Endeffekt ist die Verschlüsselung kein Hindernis für diesen Prozess. Link to comment Share on other sites More sharing options...
tamanous Posted October 16, 2012 Report Share Posted October 16, 2012 (edited) Mh ja, das kann ich jetzt besser nachvollziehen. Ich sehe meine Argumentation jedoch nicht widerlegt, da: In meiner Runde handhaben wir es meist so, dass zuerst das access log gehackt wird und dort jede Spur sofort nach Auftreten gelöscht wird -> kostet mehr Handlungen (oder agent/sprite/script), aber wenn man beim Editieren nicht bemerkt wird (Icon "steht" vor der Datei) stellt das eine recht effektive Methode unbemerkt zu bleiben dar. (Ja, die Spinne könnte das Aufblitzen einer sofort nach Auftauchen gelöschten Zeile bemerken.) In der Kopie des access logs auf Server B würde also bis bis zum Logout keine Information auftauchen, und erst beim Logout dann halt [ ID logged out ] (natürlich sofern das nicht verhindert wird). Daher meine Verwirrung. Edited October 16, 2012 by tamanous Link to comment Share on other sites More sharing options...
Ultra Violet Posted October 16, 2012 Report Share Posted October 16, 2012 Mmmh ich glaub hier ist ein Denkfehler... entweder von dir oder von mir. Das Log registriert und notiert nicht nur alle Aktionen im Node, sondern tut dies auch die ganze Zeit permanent. Soll heißen bei uns bringt es nichts das Log zuerst zu hacken es sei denn man crashed es oder schaltet es anderweitig komplett aus, welches aber im Fall des zweiten Logs sofort Alarm auslösen würde, da ja der Datenstrom unterbrochen wird. Und ein zweites Backup-Log, auf einem weiteren Node, muss erst einmal als solches erkannt werden.Der Datentransfer von Log A zu Log B ist mMn kontinuierlich und da hilft auch kein hacken/editieren, es sei denn man hackt eben auch noch Log B.Klar kann man die Infos in Log A verändern, doch Log B hat ja schon die Orginalinfos bekommen und selbst wenn ab dem Zeitpunkt nur noch falsche Daten kommen, hat Log B auch den Zugriff des Hackers auf Log A registriert und notiert. Somit zeigt dann die Überprüfung den Zugriff vom Hacker, als Manipulationsbeweis. Link to comment Share on other sites More sharing options...
tamanous Posted October 16, 2012 Report Share Posted October 16, 2012 (edited) Guter Punkt. Da muss man sich dann wirklich was einfallen lassen. Thema zweites Log finden: Ich kann mir recht gut vorstellen, dass eine Wahrnehmungsprobe bzw. eine Analyse des Logs den Datenverkehr bzw. auch den Empfänger(ID Adresse + data trail) erkennbar werden lässt. Um das zweite Log muss sich dann natürlich trotzdem erst noch gekümmert werden. Evtl fällt aber ja auch eine 2 millisec Verzögerung (reicht zum editieren von Log 1 per script/agent(delay action)) nicht großartig auf, das würde das aktive Fenster mit Log 2 überflüssig machen. Ein findiger Hacker ruft sonst kurz seinen Buddy/agent/sprite an und bittet zeitgleich Log 2 zu hacken und eben jenes Editieren dort zu initiieren... Edited October 16, 2012 by tamanous Link to comment Share on other sites More sharing options...
Ultra Violet Posted October 16, 2012 Report Share Posted October 16, 2012 (edited) Normalerweise ist der zweite Node wo Log B sich befindet gut gesichert. Aber klar es kommt immer drauf an wie sauber der Hacker arbeiten will. Und ein 2-Man-Job ist natürlich immer gut, nur nicht immer verfügbar, bzw. muss sich der Hack dann auch lohnen... Edited October 16, 2012 by Ultra Violet Link to comment Share on other sites More sharing options...
tamanous Posted October 16, 2012 Report Share Posted October 16, 2012 Hallo tanzender Winkemann, kannst du bitte ab meinem "aufwärmen"-Post (Hälfte) den Topic splitten? Ok, ich bin grad nicht so sehr auf der Höhe, muss den Gedanken aber noch zu Ende bringen. Ich denke, dass die Intercept Traffic Handlung hier anwendbar ist. Also hackt man erst den Zielknoten mit Log 1, sucht Log 1, analysiert den ausgehenden Verkehr auf eventuelle Kopien, editiert den Traffic(ab jetzt permanent), [hier könnte man bei 4-5 ID's = 1 Runde sein] hackt das Log, editiert das Log (ab jetzt permanent). Im Prinzip kann man natürlich auch direkt versuchen den Traffic herauszufiltern, aber den Gedankenstrang greife ich jetzt mal nicht auf. Warum nicht zuerst das Log hacken/editieren?Erstmal kann damit ein kurzes Refresh-Intervall entschärft werden, auf längere Sicht (die ersten drei Ini-Runden) ist es mit dem Setting dieses Topics wichtiger Log 2 das Gefahrenpotential zu nehmen. Sitzt eine Spinne an Log 1 hat sie so auch nur wenige Runden, wenn nicht nur Durchgänge Zeit, das Eindringen zu bemerken, wer weiß, ob sie gerade das Fenster aktiv hat und aufmerksam studiert ... Es bleibt dann wohl Abwägungssache (sofern man nicht weiß, ob ein Log 2 existiert), welches der beiden Risiken man eingehen möchte. Link to comment Share on other sites More sharing options...
Recommended Posts