entschlüsselte daten im arbeitsspeicher einsehbar

[TheGame1492]

hi,

also ich will eine verschlüsselte datei in mein programm einlesen

in der datei sind ftp daten um zu einem server zu connecten

wenn ich nun die datei entschlüssel, denn sind die ftp daten im arbeitsspeicher einsehbar

ich kann die daten auch nich löschen ausm arbeitsspeicher

ist es möglich die daten im arbeitsspeicher zu verschlüsseln? oder gibs da eine andere möglichkeit, damit man mir die ftp daten nicht durch den arbeitsspeicher, sniffen kann?

[Lord Dave]

Hi,

ich bin zwar kein Profi auf diesem Gebiet, aber wie soll das gehen?
Spätestens wenn die Anfrage an den Server gesendet wird, müssen die Daten doch wieder entschlüsselt sein...
Also ich halte das für unmöglich.

Je nachdem was du tun willst, musst du das Serverseitig regeln, etwa einen Read-Only FTP Account erstellen oder das ganze übe ein PHP Script laufen lassen.

[fiasko]

Hallo,

im Arbeitsspeicher ist das kein Problem - problematisch wird es nur wenn die Daten in den Swap bereich läuft, da der unter Windoof unverschlüsselt ist und man auch nix dagegen unternehmen kann. Unter Linux gibt es einen syscall mlock dafür der Speicherseiten derartig lockt das sie nicht mehr geswapt werden können - aber kA ob das auch unter Win gibt.

Du schreibst das seien FTP-Daten - sorry, aber das macht deine Überlegung gerade ziemlich witzlos - denn die FTP-Daten gehen ungeschützt beim connecten übers Netz - wozu also Aufwand betreiben die Daten in dem relativ sicheren Arbeitsspeicher zu schützen wenn die dann plain text über (inter)netz gehen ???

[TheGame1492]

Zitat:

denn die FTP-Daten gehen ungeschützt beim connecten übers Netz

ist das verbinden via SSL denn ungeschützt?

[negaH]

nur FTPS unterstützt die gesicherte Anmeldung. Meldest du dich also über normales FTP na so werden die Benutzerdaten, auch das Passwort, immer unvrschlüsselt übertragen. Bei solch geringen Sicherheitsvorkerhungen kannst du dir ein 1024 Bit Passwort ausdenkenund in einem Hochsicherheitstresor tausendfach verschlüsseln, denoch ist es im Grunde blödsinnig unsicher. Dennin dem Moment wo man es bei bormalen FTP benötigt wird es übers unsichere Netzwerk auch unverschüsselt übertragen. Da helfen auch keine Tricks wie Hash Funktionen oder so.
Erst mit FTPS wird es so lala möglichsich auf sicherer Aet&Weise übers Netz anzumelden. Somit wird es dann auch sinnvoll sich Gedanken über den Schutz im Speicher zu machen.

Generell gilt:
- lebenszeit im Speicher zu kurz wir möglich
- Speicherbereiche vor dem Freigeben mehrmals übrschreiben
- Speicherbereiche am besten im Anwendungs-Stack platzieren da dies die allerletzten Speicherbereiche sind die in die Swap-Dateien ausgelagert werden.
- wenn es möglich ist die Passwörter immer nur sequentiell entschlüseln und byteweise sequentiell sofort damit Berechnungen anstellen. Soll heisen nachdem 1 Byte des Passwortes entschlüsselt wurde wird damit sofort gerechnetund danach diese eine Byte überschrieben. Im Idealfalle landet so das "Passwort" nur in den CPU Registern, sequentiell und Byteweise. Das kann das OS niemals auslagern oder so einfach gehackt werden.

Gruß Hagen

[Lord Dave]

Hi,

also ich verstehe immernoch nicht, wie das Passwort dann übertragen werden soll ?!
Spätestens bei der Übermittlung muss das PW ja wieder unverschlüsselt sein, d.h. mit nem Debugger nen richtigen Breakpoint gesetzt bekommt man das (im Notfall byteweiße) wieder raus, oder nicht?

[negaH]

Zitat:

also ich verstehe immernoch nicht, wie das Passwort dann übertragen werden soll ?!

Habe ich oben doch schon gesagt -> es wird unverschlüsselt übertragen !!
Dies trifft auf normales FTP oder auch Basic Authentications bei Proxies und HTTP Servern zu. Die Anwendung einer Hashfunktion macht es nicht besser.

Und weil das Passwort unverschlüsselt zur Übertragung benötigt wird muß es auch unverschlüsselt im Speicher liegen und als Parameter übergeben werden. Somit hat es gar keinen Sinn sich Gedanken zu machen es sicher und verschlüsselt im Speicher abzulegen, da es zum entsprechenden Zeitpunkt eh immer ungeschützt sein wird.

Anders sieht es bei FTPS oder sogar SRP -> Secure Remote Password/Protokoll aus. Diese Verfahren arbeiten nach ganz ganz anderen Techniken. Nur zu einem ganz ganz kurzen Zeitpunk wird das reale Passwort benötigt. Mit diesem werden dann die relevanten Daten berechnet, und danach kann das Passwort sofort zerstört werden (im Speicher). Die damit erzeugten Daten sind dann für den Server ein "Beweis" dafür das der "Client" das eigentliche Passwort kennt. D.h. es wird nicht mehr das Passwort übertragen, sondern nur zu zufällig vorgegebenen Daten eine "Prüfsumme" die nur derjenige erzeugen kann der das Passwort kennt. Mit diesen Daten kann man sich NUR zum aktuellen Zeitpunkt am Server einloggen. Somit nützt ein Angriff hier garnichts, da beim nächsten Login wieder ganz andere Daten benutzt werden. Soweit erst mal ganz ganz vereinfacht dargestellt

Gruß Hagen

[Sharky]

Hai Hagen,

eine kleine Frage: (Auch wenn es nicht "direckt" zur Ursprungsfrage gehört).

Wie Sicher wäre es denn wenn ich mit einem eigenen FTP-Client und Server arbeite und für das Kennwort das Verfahren genutzt wird das Du in diesem Therad beschrieben hast.
Dann könnte zwar jemand das unverschlüsselte Passwort abhören aber er könnte sich nicht damit anmelden.

[fkerber]

Hi!

Hätte da auch noch eine Frage (passt halbwegs zur Ausgangsfrage, geht allerdings nicht um FTP)
Und zwar folgendes:

Ich habe verschiedene Dateien, die wieder entschlüsselt werden, um mit ihnen arbeiten zu können (Sinn ist nicht, die Dateien zu entschlüsseln, sondern an Daten ranzukommen, die in den Dateien drin sind und mit ihnen zu arbeiten - danach wird wieder verschlüsselt)
Dafür muss ich die komplette Datei ja komplett entschlüsseln und solange unverschlüsselt lassen, wie mit ihr gearbeitet wird.

Wie sieht es da mit Auslesen aus dem Arbeitsspeicher aus?


Ciao Frederic

[negaH]

@sharky,

OPT S/KEY gilt nach neuesten Studien als unsicher. Nicht das Verfahren an sich, also der Algirthmus, sondern das Protokoll und die Datenhaltung auf den Servern. Wurde ein Server kompromitiert so reist dieser Server die Sicherheit der Benutzer auf anderen Servern ein. D.h. die Wahrscheinlichkeit das andere Server ebenfalls kompromitiert werden steigt.

Ich empfehle dir mal das SRP = Secure Remote Password Protocol anzuschauen.

@fkerber,

es macht KEINEN Sinn den eigenen Rechner als Festung nach Innen zu betrachten. Wurde in den Rechner einmal eingebrochen so ist er unsicher. Man kann ihn mit heutigem Windows-OS, ich behaupte sogar mit reiner Software NIEMALS sicher vor inneren Angriffen schützen. Das ginge nur mit einem sicheren OS das auf sicherer Hardware basiert. Somit ist es klar das man sich nicht allzuviel Zeit nehmen sollte um seine eigene Software gegen Software auf dem gleichen System zu schützen. Einige Grundregeln sollte man beachten, aber mehr auch nicht, da die Zeit die man investiert sich nicht rentiert.

- geheime Daten zeitlich so kurz wie möglich entschlüsselt halten
- geheime Daten möglichst in den flüchtigsten Medienspeichern, -> RAM Speicher -> Stackbereich -> Register
- geheime Daten möglichst dort verstecken wo man auf große und ständig veränderliche Datenmengen stösst
- Schlüssel per Definition mit einem Verfallsdatum versehen, um so kürzer diesist um so öfter muß man Schlüssel wechseln um so höher die Sicherheit
- geheime Daten getrennt verwalten, speichern und verschlüsseln, dies erhöht den Gesamtaufwand

Mit diesen Grundregeln im Hinterkopf kann man leicht seine eigene Software mit leichten Mitteln sicherer machen.

Gruß Hagen