Paßwort aus RAM lesbar per Firewire

[Bananenbieger]

Andersherum hätte es besser gepasst: Das Passwort wird nur solange benötigt, bis daraus der gewünschte Hash erzeugt wurde. Und zur Prüfung muss nur noch neuer Hash mit gespeichertem Hash verglichen werden.

Nicht, wenn man das Passwort noch mal benötigt. Der Hash wird ja immer dort vom PW erzeugt, wo er verglichen werden soll. Die "Passwortquelle" hat immer das Klartextpasswort in wiederherstellbarer Form zu haben (sei es unser Gehirn, der Schlüsselbund oder 1Password)

Mit dem im Keychain gesicherten Hash, der als eigentlicher Schlüssel dient.

Ah, danke. War mir neu.

 

[ImperatoR]

Und wie glaubst du die lesen zu können ohne sie dazu im Arbeitsspeicher abzubilden?

Ja es ist schon sehr knifflig. Aber was ist wenn der Prozessor auf dieses Gerät direkt zugreift? Und sich dann direkt den Wert (aka Schlüssel) vom Gerät auf die Register holt um die Ver- bzw. Entschlüsselung vorzunehmen und den Wert danach wieder verwirft?

Register sollte man ja damit nicht auslesen können.

(Ein Porno wirkt dagegen wie eine Modenschau der Winterkollektion - in Sibirien.)

Made my day!

 

[Rastafari]

Nicht, wenn man das Passwort noch mal benötigt.

Um den bzw die gleichen Hashes erneut zu erzeugen? Dürften sich kaum ändern.

Aber was ist wenn der Prozessor auf dieses Gerät direkt zugreift?

...dann ist das im Detail nichts anderes als ein Zugriff auf abgebildete Adressen im RAM.
So kommunizieren Computerkomponenten nun mal: Sie stellen ihre Informationen an bestimmten Speicheradressen zur Verfügung und holen neue auch von solchen ab.
(Nur sehr wenige Elemente der Hardware beherrschen überhaupt andere Kommunikationsformen, aber die haben nichts mit den zu verarbeitenden Daten zu tun, die kommen damit nie in Berührung. Die steuern den Ablauf des Informationsflusses nur, nehmen aber selbst nicht daran teil.)
Es gilt ohne Ausnahme:
Daten, die dein Prozessor lesen, verarbeiten und wieder schreiben kann, kann auch der entfernte Rechner lesen und schreiben. (Zwar immer nur kleinere, wechselnde Abschnitte davonn, aber das spielt keine Rolle.)

 

[Bananenbieger]

Um den bzw die gleichen Hashes erneut zu erzeugen? Dürften sich kaum ändern.

Man schickt wohl kaum Hashes z.B. an entfernte Rechner.

 

[naich]

Und Passwörter für entfernte Rechner (ssh, ftp usw.) sind ja wenn dann im Schlüsselbund gespeichert - aus dem sie auch ad hoc ausgelesen werden können.

 

[Rastafari]

Man schickt wohl kaum Hashes z.B. an entfernte Rechner.

Aber selbstverständlich doch. Was denn sonst, Klartext etwa?

 

[Bananenbieger]

Aber selbstverständlich doch. Was denn sonst, Klartext etwa?

Ein Hash über eine unverschlüsselte Verbindung ist doch nichts anderes als ein Klartext-Passwort.

 

[Rastafari]

Und wer wäre so doof, ihn unverschlüsselt zu übertragen?
Genauer gesagt - wer wäre so blöd, ihn überhaupt zu übertragen?

 

[MacMark]

Ein Hash über eine unverschlüsselte Verbindung ist doch nichts anderes als ein Klartext-Passwort.

Man prüft mit dem Hashwert, ob ein Paßwort korrekt ist. Der Hashwert selbst ist jedoch kein Paßwort.

Und Passwörter für entfernte Rechner (ssh, ftp usw.) sind ja wenn dann im Schlüsselbund gespeichert - aus dem sie auch ad hoc ausgelesen werden können.

Wenn die Keychain den betreffenden Schlüssel gerade freigibt, so daß er im RAM liegt, ja. Die Keychain-Daten nicht den ganzen Tag im RAM.

FTP sollte nicht mehr genutzt werden, sondern SFTP, was die Paßworte ähnlich wie SSH über eine verschlüsselte Verbindung überträgt.

 

[Loooki]

FTP sollte nicht mehr genutzt werden, sondern SFTP, was die Paßworte ähnlich wie SSH über eine verschlüsselte Verbindung überträgt.

Oder mit einem ssh Tunnel ....

 

[Bananenbieger]

Und wer wäre so doof, ihn unverschlüsselt zu übertragen?
Genauer gesagt - wer wäre so blöd, ihn überhaupt zu übertragen?

Ich glaube, Ihr versteht mich nicht: Wenn ich ein Passwort für was auch immer wieder im Klartext benötige (eben z.B. bei einer entfernten Anmeldung), dann kann ich es nicht hashen, da das ja bekanntlich eine Einbahnstraße ist. Hashes werden ja bekanntlich in den meisten Fällen auf dem Zielsystem vom wie auch immer übertragenen Klartextpasswort erzeugt und erst dann mit dem hinterlegten Passwort-Hash verglichen. Nicht mehr oder weniger wollte ich mit meinen Beiträgen sagen.

 

[Rastafari]

Hashes werden ja bekanntlich in den meisten Fällen auf dem Zielsystem vom wie auch immer übertragenen Klartextpasswort erzeugt

Der letzte Dienst bei dem das so gemacht wurde, war Telnet. Jetzt weisst du, warum das ausgestorben ist.

Schon mal was von "Challenge-Response" Verfahren gehört?

Prinzip:
1) Die geheimen Hashes sind dem Zielsystem längst bekannt (die Kennworte nicht, und das ist gut so).
2) Das Zielsystem erhält eine Bitte um Anmeldung, d.h. eine notwendige Authentifizierung.
3) Das Zielsystem nimmt daraufhin den zur Anmeldung erforderlichen geheimen Hash, ergänzt ihn um eine frisch erzeugte Zufallszahl und bildet aus dieser neuen Zeichenkette einen völlig neuen, rein temporären Hashwert.
4) Die hierfür verwendete Zufallszahl wird ans Quellsystem als "Challenge" übermittelt.
5) Das Quellsystem kennt den geheimen Hash ebenfalls und führt die gleiche Prozedur mit der erhaltenen Zufallszahl damit aus.
6) Quellsystem sendet seine eigene Version des temporären Hash ans Zielsystem zurück (Response).
7) Zielsystem vergleicht die beiden temporären Hashes. Stimmen sie überein, dann kannte das Quellsystem den geheimen Hash --> Authentifizierung erfolgreich, Zugang wird gewährt.

Ergo: Weder das Kennwort noch ein gespeicherter Hash werden jemals im Netz übertragen, sondern nur ein temporärer Hashwert, der nur ein einziges mal zur Anwendung kommt und dann sofort ungültig wird. Das Klartextpasswort wird nicht mehr benötigt. So einfach geht das.

 

[Bananenbieger]

Schon mal was von "Challenge-Response" Verfahren gehört?
[...]
Ergo: Weder das Kennwort noch ein gespeicherter Hash werden jemals im Netz übertragen, sondern nur ein temporärer Hashwert, der nur ein einziges mal zur Anwendung kommt und dann sofort ungültig wird. Das Klartextpasswort wird nicht mehr benötigt. So einfach geht das.

Tja, schau einfach mal in den Sourcecode diverser Webanwendungen/-browser.

 

[Rastafari]

Tja, schau einfach mal in den Sourcecode diverser Webanwendungen/-browser.

Safari speichert Webkennworte in einer verschlüsselten Datenbank. Kein Grund, sie im RAM zu halten.
Und erst recht kein Grund für dich, für die Anmeldung am System und irgendwelche Webseiten die gleichen Kennworte zu verwenden.

 

[Bananenbieger]

Und wie viele Leute verwenden nur ein Passwort für alles?

 

[Macbeatnik]

Und wie viele Leute verwenden nur ein Passwort für alles?

In meinem Bekanntenkreis fast jeder, dort gibt es immer wieder Gemotze, wenn das angestammte Passwort bei einem neuen Dienst nicht akzeptiert wird, da dort dann ein Fenster aufploppt und lapidar mitgeteilt wird, das das Passwort mindestens 6 Buchstaben und einige Zahlen lang sein muss. Kein Scherz und da kann ich reden, wie ich will, gegen diese Unart kommt man nicht an.

 

[ImperatoR]

Es muss erst was passieren, dass sie sich anders verhalten. Backups werden auch erst gemacht, wenn man bei einem Festplattencrash viele Daten verloren hat etc.

 

[Macbeatnik]

Es muss erst was passieren, dass sie sich anders verhalten. Backups werden auch erst gemacht, wenn man bei einem Festplattencrash viele Daten verloren hat etc.

Mein reden, einige haben sogar ein Backup und einige hatten es sogar auf einem RAID1( auch da habe ich vergeblich gegenan gestunken), bis sie dann bemerkten, natürlich erst nach einem Fehler, das RAID und Backup in den allermeisten Fällen einander ausschliessen.

 

[Bananenbieger]

Bleibt aber halt die Frage, warum das Passwort im RAM liegt, wenn es ja scheinbar nicht im Klartext unter OSX benötigt wird.

 

[lx88]

Jetzt wird's wieder spannend! ...
Auch wenn diese kleine Exkursion meinem Verständnis der Materie definitiv nicht geschadet hat :-D