nicht angemeldet
Der Martin
Rolf B
localhorst
Felix Riesterer
Der Martin
Rolf B
Gunnar Bittersmann
Der Martin
localhorst
Rolf B
Linuchs
localhorst
Hallo,
mein PHP-Script bekommt einen Anhang als Base64 encoded zugesendet. In meinem Tests ist es eine einfache TXT-Datei mit dem Inhalt "Dies ist ein Test". Laut base64.guru ist der Base64-String fehlerfrei.
Kann ich mit PHP a) aus dem Base64-String wieder eine Datei erstellen? b) ohne Speichern auf den Inhalt der TXT-Datei zugreifen (z.B. um diesen zu durchsuchen)?
(Der Anhang wird von einem Notes-Server über DXL Export in Base64 umgewandelt und dann an das Script übertragen)
Alle meine bisherigen Versuche sind fehlgeschlagen, es kommt einfach nichts brauchbares zurück.
Ein base64_decode($text); reicht sicher nicht alleine, da es ja nicht nur der Inhalt, sondern auch die Datei-Informationen sind.
Aber auch ein
kai345
Matthias Apsel$ori = base64_decode($test);
$file = fopen('/tmp/test.txt', 'w');
fwrite($file, $ori);
fclose($file);
erzeugt nur Müll in der Datei.
Dasselbe bei file_put_contents('/tmp/test.txt'm, $ori);
Hier der Base64-String:
lQAmAAAAAAAAAAAAAAABAAAAAAAAADgAIgAIAAEACAABABYAAwCWAEgCAAAAAAAAAAAAACIANgJABwBABwBAAgABAMgFyAYCBQpAAgDFAEACAAIABc4ABAUSBQpAAgDEAEACAAIABc4ABQUCERQKQAIAwwBAAgACAAXOAAEFwgoDEQYKQAIAwgBAAgACAAXOAAEFwgoDEhUGQAIAwgBAAgADAAUAzAECAAXEBwEJQAIAwgBAAgACAAXOAAEKww0CCglAAgDCAEACAAIABc4AwwQDAwAQQAIAwgBAAgADAAYAQAIBAwEAD0ACAMIAQAIAAgAGzQDEBAMDAAdAAgDCAEACAAIABs0AwwTCAwIAB0ACAMIAQAIAAwAGAEACAQMBAAdAAgDCAEACAAIABssAxATDAwIAB0ACAMIAQAIAAgAGygDEBMQDAgAHQAIAwgBAAgADAAYAQAIBAwEAB0ACAMIAQAIAAgAGxwDFBMYDAgAHQAIAwgBAAgACAAbFAMYExgMDAgALQAIAwgBAAgADABMAQAIBAwEAC0ACAMIAQAIAAwAJAMcExwPDAgIADkACAMIAQAIAAwAJAMUEyAPEAgIACEACAMIAQAIAAwAJAEACAQMBAAhAAgDCAEACAAMACQDKA8cCAgAIQAIAwgBAAgADAAkAyAPJAgIACEACAMIAQAIAAwAJAEACAQMBAAhAAgDCAEACAAMACQBAAgIDAgAIQAIAwgBAAgADAAkAQAICAwIACEACAMIAQAIAAgAJQAIAwwABDEACAMIAQAIAAwAQD8cHwgsBDscIwgxAAgDCAEAHAEAHAEAHAEAHAJcASAAAAP///6ioqPDw8PDw+PD4+KCgoJiYmIiIiICAgJCQkOjo6ICIiHiAgODo6ICAiIiIkIiQkNjY2ODg4JCYmJigoNDQ0JgATgAAAAAAAAAAAAAARUFENjgyOF81MzU2AAAAAAEBAQEBAQEBIgAAAAAAAAAqAAAAGgAAAAICAgICAgIC+v/d3S4W3d2AHgEA3BIAAA==
Habt ihr noch eine Idee?
LG Klaus
Hallo Klaus,
mein PHP-Script bekommt einen Anhang als Base64 encoded zugesendet. In meinem Tests ist es eine einfache TXT-Datei mit dem Inhalt "Dies ist ein Test". Laut base64.guru ist der Base64-String fehlerfrei.
aber anscheinend ist bei der Erzeugung des base64-Strings trotzdem irgendwas schiefgegangen.
Kann ich mit PHP a) aus dem Base64-String wieder eine Datei erstellen? b) ohne Speichern auf den Inhalt der TXT-Datei zugreifen (z.B. um diesen zu durchsuchen)?
Zweimal ja.
(Der Anhang wird von einem Notes-Server über DXL Export in Base64 umgewandelt und dann an das Script übertragen)
Aha. Dann vermute ich mal ganz stark, dass die Originaldaten eben nicht Plain Text sind, sondern ein Lotus-internes Format.
Ein
base64_decode($text);reicht sicher nicht alleine, da es ja nicht nur der Inhalt, sondern auch die Datei-Informationen sind.
Nein, normalerweise nicht. Bei einem e-Mail-Anhang stehen die Meta-Daten wie Dateiname, MIME-Typ und Größe in den Headerzeilen des jeweiligen Blocks. Die base64-Daten stellen ausschließlich den Dateiinhalt dar.
$ori = base64_decode($test); $file = fopen('/tmp/test.txt', 'w'); fwrite($file, $ori); fclose($file);erzeugt nur Müll in der Datei.
Kann ich bestätigen.
lQAmAAAAAAAAAAAAAAABAAAAAAAAADgAIgAIAAEACAABABYAAwCWAEgCAAAAAAAAAAAAACIANgJABwBABwBAAgABAMgFyAYCBQpAAgDFAEACAAIABc4ABAUSBQpAAgDEAEACAAIABc4ABQUCERQKQAIAwwBAAgACAAXOAAEFwgoDEQYKQAIAwgBAAgACAAXOAAEFwgoDEhUGQAIAwgBAAgADAAUAzAECAAXEBwEJQAIAwgBAAgACAAXOAAEKww0CCglAAgDCAEACAAIABc4AwwQDAwAQQAIAwgBAAgADAAYAQAIBAwEAD0ACAMIAQAIAAgAGzQDEBAMDAAdAAgDCAEACAAIABs0AwwTCAwIAB0ACAMIAQAIAAwAGAEACAQMBAAdAAgDCAEACAAIABssAxATDAwIAB0ACAMIAQAIAAgAGygDEBMQDAgAHQAIAwgBAAgADAAYAQAIBAwEAB0ACAMIAQAIAAgAGxwDFBMYDAgAHQAIAwgBAAgACAAbFAMYExgMDAgALQAIAwgBAAgADABMAQAIBAwEAC0ACAMIAQAIAAwAJAMcExwPDAgIADkACAMIAQAIAAwAJAMUEyAPEAgIACEACAMIAQAIAAwAJAEACAQMBAAhAAgDCAEACAAMACQDKA8cCAgAIQAIAwgBAAgADAAkAyAPJAgIACEACAMIAQAIAAwAJAEACAQMBAAhAAgDCAEACAAMACQBAAgIDAgAIQAIAwgBAAgADAAkAQAICAwIACEACAMIAQAIAAgAJQAIAwwABDEACAMIAQAIAAwAQD8cHwgsBDscIwgxAAgDCAEAHAEAHAEAHAEAHAJcASAAAAP///6ioqPDw8PDw+PD4+KCgoJiYmIiIiICAgJCQkOjo6ICIiHiAgODo6ICAiIiIkIiQkNjY2ODg4JCYmJigoNDQ0JgATgAAAAAAAAAAAAAARUFENjgyOF81MzU2AAAAAAEBAQEBAQEBIgAAAAAAAAAqAAAAGgAAAAICAgICAgIC+v/d3S4W3d2AHgEA3BIAAA==
Das ist irgendein für mich nicht erkennbarer Binärmüll.
Live long and pros healthy,
Martin
Hallo Martin,
Binärmüll
Nicht ganz, kurz vor Ende steht NEAD6828_5356. Aber das kann Zufall sein.
DXL sollte dagegen ein XML Format sein. Entweder ist also das Base64-Fragment unvollständig, oder Notes hat das bekannte Problem jeder Software: Sie tut genau das, was man ihr sagt. Und nicht das, was man will.
Laut base64.guru ist der Base64-String fehlerfrei.
Klaus, Base64 ist eine Technik, um beliebige Bytefolgen "drei in vier" zu verschlüsseln. D.h. man nimmt die 24 Bits von jeweils 3 Bytes und teilt sie in vier Gruppen zu je 6 Bit auf (was 64 mögliche Werte ergibt). Jedem dieser Werte wird ein ASCII-Zeichen zugeordnet. Verschlüsselt man Müll, kommt immer noch ein korrekter Base64-String heraus. Aber leider nur korrekt verschlüsselter Müll.
Das Problem ist vor der base64-Verschlüsselung.
Rolf
Hallo Rolf
Verschlüsselt man Müll, kommt immer noch ein korrekter Base64-String heraus. Aber leider nur korrekt verschlüsselter Müll.
YMMD
Eine ideale Methode, um die Rechner der NSA zum Glühen zu bringen. An der Verschlüsselung rechnen die sich einen Wolf.
Grinsende Grüße
localhorst
Lieber Rolf,
Klaus, Base64 ist eine Technik, um beliebige Bytefolgen "drei in vier" zu verschlüsseln.
lass' mich da ein bisserl klugscheißen: Um eine Verschlüsselung handelt es sich erst, wenn ein Geheimnis (aka Passwort, Passphrase etc.) zum Einsatz kommt, ohne dieses der Vorgang nicht umkehrbar ist. Bei Base64 handelt es sich "lediglich" um eine Kodierung.
Liebe Grüße
Felix Riesterer
Hallo Felix,
Klaus, Base64 ist eine Technik, um beliebige Bytefolgen "drei in vier" zu verschlüsseln.
lass' mich da ein bisserl klugscheißen: Um eine Verschlüsselung handelt es sich erst, wenn ein Geheimnis (aka Passwort, Passphrase etc.) zum Einsatz kommt, ohne dieses der Vorgang nicht umkehrbar ist. Bei Base64 handelt es sich "lediglich" um eine Kodierung.
das ist völlig korrekt. Aber zumindest umgangssprachlich werden die Begriffe verschlüsseln, codieren[1], seltener auch chiffrieren quasi synonym verwendet.
Solange der Kontext eindeutig ist, muss man da IMO nicht päpstlicher sein als der Papst.
Live long and pros healthy,
Martin
mit k sieht's irgendwie caputt aus, finde ich ↩︎
Hallo Martin,
päpstlicher als der Papst muss man nicht sein, aber sollte man gleich ungetaufte Zelebranten an den Altar schicken? <ironie>Oder gar Frauen?[1]</ironie>
[CK]odierung und Verschlüsselung sind schon von sehr unterschiedlicher Qualität und ich finde, dass ich da zu Recht korrigiert wurde. Eine Verschlüsselung braucht einen Schlüssel. Bei Base64 gips keinen.
Rolf
Was aus Sicht einiger Kurienstarrköpfe vermutlich schlimmer ist ↩︎
@@Rolf B
Eine Verschlüsselung braucht einen Schlüssel. Bei Base64 gips keinen.
Willst du damit sagen, ROT13 wäre keine Verschlüsselung? 😏
😷 LLAP
Eine Verschlüsselung braucht einen Schlüssel. Bei Base64 gips keinen.
Willst du damit sagen, ROT13 wäre keine Verschlüsselung? 😏
ROT13 ist ein Witz. Viel zu simpel. Ich nehme immer ROT26 oder doppeltes ROT13.
Hallo,
Bei Base64 gips keinen.
Gips gips inner Gipsfabrik.
Wenn's da nix gips, dann gips kein Gips.
Live long and pros healthy,
Martin
Hallo Martin,
päpstlicher als der Papst muss man nicht sein, aber sollte man gleich ungetaufte Zelebranten an den Altar schicken? <ironie>Oder gar Frauen?[1]</ironie>
[CK]odierung und Verschlüsselung sind schon von sehr unterschiedlicher Qualität und ich finde, dass ich da zu Recht korrigiert wurde. Eine Verschlüsselung braucht einen Schlüssel. Bei Base64 gips keinen.
Das kommt auf die Verschlüsselung an. Ich würde einen One(way|time)hash auch als Verschlüsselung bezeichnen mögen, obwohl kein Schlüssel benötigt wird.
Aber für einen Laien (d|w|m) sieht ein Base64-Text auch wie verschlüsselt aus.
LG
localhorst
Was aus Sicht einiger Kurienstarrköpfe vermutlich schlimmer ist ↩︎
Hallo localhorst,
erklär mir doch grad, was Du unter One(way|time)hash verstehst.
Ich habe das fast mit One-Time Pad verwechselt. Und meine Google-Suche findet jede Menge akademisches Zeug, das mir jetzt zu lang zum Lesen ist (und von dem ich nicht weiß ob Du es meinst).
Rolf
Hallo Rolf,
erklär mir doch grad, was Du unter One(way|time)hash verstehst.
Ich habe das fast mit One-Time Pad verwechselt. Und meine Google-Suche findet jede Menge akademisches Zeug, das mir jetzt zu lang zum Lesen ist (und von dem ich nicht weiß ob Du es meinst).
Das ging mir ähnlich, als ich nach dem richtigen™ Ausdruck für nur forwärts gesucht habe. Schließlich kann man md5 nicht wieder "entschlüsseln". Dass es nur eine statistische "Sicherheit" hat, ist ohnehin klar ud dass es inzwischen auch in Frage gestellt wird (Rainbow Tables u. ä.), ist mif auch klar.
Also, wie lauten die etablierten Fachbegriffe für diese Art der (impliziten) Verschlüsselung, Prüfnummernbildung, ...?
LG
localhorst
Hallo localhorst,
jetzt bin ich wieder dabei. Onewayhash ist schon richtig dafür. Oder Falltürfunktion.
Ein brauchbarer Hash Algorithmus für Passwörter hat serverseitig einen Schlüssel (seed), damit ein Dieb nichts mit der geklauten Datenbank anfangen kann. Und Salz im Passwort, damit die Rainbow-Tables nicht helfen. Also ja, ist eine Verschlüsselung ohne Rückweg.
Rolf
Hallo Rolf,
jetzt bin ich wieder dabei. Onewayhash ist schon richtig dafür. Oder Falltürfunktion.
Ein brauchbarer Hash Algorithmus für Passwörter hat serverseitig einen Schlüssel (seed), damit ein Dieb nichts mit der geklauten Datenbank anfangen kann.
Das irritiert mich jetzt allerdings!
Hieße das etwa, dass eine Portierung meines Webs auf einen anderen Host bzw. andere Server dazu führen würde, dass kein Login mehr funktioniert?
Soll heißen:
Führt die md5()-Funktion üblicherweise auf jedem Host (ähnlicher Version) zum selben Ergebnis, oder kann ich die login-table nicht einfach von einem Host zum anderen übertragen?
Irritierte Grüße
localhorst
Hallo localhorst,
ich glaube, ich habe das was falsch im Kopf gehabt. Die password_hash Funktion bekommt keinen Key.
Aber die md5-Funktion solltest Du dringend entfernen. md5 gilt als gehackt.
Heißt: der Login-Tabelle ein Feld hinzufügen das ein Kennzeichen für die verwendete Hashfunktion enthält.
User, die sich anmelden und einen MD5 Hash haben, werden zur Kennwortänderung aufgefordert. Bei der Änderung wird nach neuem Verfahren gehasht.
Du kannst natürlich auch still und heimlich beim Login das Passwort rehashen und den neuen Hash in die DB schreiben. Aber da ein md5-Hash als kompromittiert zu betrachen ist, würde ich das als weniger sicher bezeichnen.
Rolf
Hallo localhorst,
die md5-Funktion meines Wissens schon, aber die solltest Du dringend entfernen. md5 gilt als gehackt.
md5() ist nicht "gehackt" worden, da die Funktionsweise ja schon immer bekannt war. Es gab also keine Geheimnisse zu hacken.
Eine Konsolidierung von Daten mittels md5() ist bestenfalls unsicherer geworden, da 128 Bit heute nicht mehr ausreichen, um genügend Zeit zu schinden, und derartige Hashes keine Ablaufdaten enthalten.
Ich nenne das ab jetzt "single sign", da ja keinem anderen Dokument derselbe Hash zugeordnet werden sollte - bis auf die Milliarden unplausiblen anderen und gefakten Doks. Da wird man dann im Einzelfall durch Kontext entscheiden müssen, oder.
md5() ist ohne Kontextbewertung IMHO nicht sinnvoll.
Paranoide Grüße
localhorst
Ein brauchbarer Hash Algorithmus für Passwörter hat serverseitig einen Schlüssel (seed), damit ein Dieb nichts mit der geklauten Datenbank anfangen kann. Und Salz im Passwort, damit die Rainbow-Tables nicht helfen. Also ja, ist eine Verschlüsselung ohne Rückweg.
Naja... das ist ein wenig zu einfach.
Ich versuchs mal zu erklären:
Entropie: Im hier betrachteten Sinn ist die eine Folge von Bytes, die durch „zufällige“ Ereignisse gebildet wird. In Frage kommt hierfür alles, was auf einem Rechner oder Server messbar aber schwer vorhersehbar ist ist. z.B. Netzwerkverkehr, Datenverkehr über Busse (Beispielsweise: USB - Tastendrücke, Mausbewegungen) Temperaturen von CPU-Kernen, Taktfrequenzen derselben, Rotationsgechwindigkeiten von Ventilatoren, …) Man nennt das auch „environmental noise“ also „Umgebungsrauschen“ welches quasi aufgenommen und in einem FIFO entnehmbar gespeichert wird.
Diese Entropie ist endlich und auf Grund des Fehlens von Tastatur und Maus auf Servern dort begrenzter als auf Desktops.
Zufallsfunktion: Im hier betrachteten Sinn eine Funktion, die bei jedem Aufruf eine andere Folge von Bytes zurückgibt. Gängige Zufallsfunktionen nutzen hierbei die Entropie um „echten“ Zufall zu produzieren. Ist die gespeicherte Entropie verbraucht gibt es zwei Verfahrensweise: warten oder Übergang zu einer rein mathematischen Funktion, bei welcher irgendwann die Folge der „zufälligen“ Werte von vorn beginnt, wodurch der gelieferte Wert vorhersagbar wird.
Lesestoff liefert ein man 4 random auf Linux-Systemen.
Seed: Um die Vorhersehbarkeit der Ergebnisse des mathematischen Quasizufalls zu vermindern wird der Zufallsfunktion quasi eine Anzahl von Nutzungen vorgemacht. Der Seed ist also ein nicht übergebener, sondern individuell festgelegter wert, der in der Zufallsfunktion genutzt wird.
Lesestoff liefert ein man 2 getrandom auf Linux-Systemen.
Salt: Mittels obiger Zufallsfunktionen gebildete Bytes, die einem „Text“ vorangestellt werden, bevor ein Hashalgorythmus auf den mit dem Salt vereinten Text angewendet wird. Die Länge wird definiert.
Hashalgorithmus: „Abbildung, die eine große Eingabemenge (die Schlüssel) auf eine kleinere Zielmenge (die Hashwerte) abbildet. … Die Eingabemenge kann Elemente unterschiedlicher Längen enthalten, die Elemente der Zielmenge haben dagegen meist eine feste Länge.“ Wikipedia
Rainbow-Tables: Da gängige Passwörter eine begrenzte Länge haben und Massenspeicher sehr günstig ist, ist es inzwischen sogar Privatpersonen möglich zumindest bei schwachen Hashalgorithmen wie MD5 mit kurzer Ausgabemenge (128 Bit) möglich für jeden denkbaren Hashwert eine Eingabe zu speichern und diese abzufragen. Würden Passwörter also mit MD5 gehasht, so kann ein Angreifer aus dem Hash ein gültiges Passwort ermitteln. Das muss nicht das ursprüngliche sein.
Aktuelle Passwort-Hash-Funktionen gehen wie folgt vor:
„Verschlüsseln“: Es wird der möglichst zufällige Salt ermittelt. Das Passwort wird mit dem Salt verknüpft und dann beides zusammen mit einem möglichst starken Hashalgorithmus gehasht. Danach wird das Resultat wieder mit dem Salt verknüpft und erneut gehascht. Dieser Vorgang wird in einer endlichen Anzahl wiederholt. (Loops) Als Resultat wird dann ein Hinweis auf den Hashalgorithmus, die Anzahl der Loops, der Salt und das letze Resultat der Anwendung des Hashalgorithmus gespeichert. In PHP: password_hash()
Ein „Entschlüsseln“ findet nicht statt: Aus der Datenbasis wird das „verschlüsselte“ Passwort mit den Informationen: Salt, Hashalgorithmus und Loops geholt. Das eingebenene Passwort ird jetzt wie unter 1. mit diesen Informationen erneut verschlüsselt und dann das Resultat verglichen. In PHP: password_verify()
„Updates“: Findet die Passwortfunktion nach einem Update der Programmiersprache anhand der Kennzeichnung in dem Resultat des früheren Verschlüsselns heraus, dass ein unsichereres Verfahren als möglich angewendet wurde (in PHP: password_needs_rehash() ), dann kann der Programmierer vorsehen, dass nach positiver Verifizierung das also bestätigte und bekannte Passwort mit dem sichereren Verfahren erneut „verschlüsselt“ und gespeichert wird - und das ohne dass der Benutzer hiermit behelligt wird.
Hallo Rakete,
gut geschrieben! Das muss ins Wiki :-)
Würden Passwörter also mit MD5 gehasht, so kann ein Angreifer aus dem Hash ein gültiges Passwort ermitteln. Das muss nicht das ursprüngliche sein.
Das ist der Knackepunkt. 128 Bit sind eben nicht mehr viel. Dafür kann man heutzutage bedenkenlos eine direkt gestreute Tabelle aufbauen.
3,40282367E+38 Zeilen mit 24 bis 32 Bytes Breite, oder komfortabel auch mit 152 Bytes pro Datensatz (16Bytes Hash und je ein Wert für Passworte mit 1 bis 16 Zeichen Länge).
Wenn man zum Hash die Länge des erforderlichen Passwortes mit abspeichert kann man die "Sicherheit" geringfügig erhöhen.
Sollte mich wundern, wenn es noch keinen Dienst für die Ermittlung zumindest eines Passwortes zum Hash im Internet geben würde.
Paranoide Grüße
localhorst
Hallo Raketenerklärbär,
ist es inzwischen sogar Privatpersonen möglich zumindest bei schwachen Hashalgorithmen wie MD5 mit kurzer Ausgabemenge (128 Bit) möglich für jeden denkbaren Hashwert eine Eingabe zu speichern und diese abzufragen.
Das rechne mal nach. Wir leben derzeit in der Zettabyte-Ära, und man schätzt das weltweite Datenvolumen für 2020 auf 40 ZB. Das sind 4x10^22 oder ca. 2^75 Bytes. Bis zur 2^128 sind noch 53 Bit Luft - wenn sich die Datenmenge auf der Welt, wie geschätzt, alle 2 Jahre verdoppelt, dann sind wir in 106 Jahren bei so vielen Bytes angekommen. Also, nein, sooo schwach ist MD5 auch nicht.
Die Schwäche von MD5 liegt darin, dass ein Hash relativ fix berechnet ist und dass es Kollisionsangriffe gibt (d.h. zwei Nachrichten mit gleichem Anfang liefern den gleichen Hash). Damit ist MD5 zum Signieren ungeeignet.
Beim Ermitteln von Passwörtern hast Du aber die Aufgabe, zu einem gegebenen Hash einen Klartext zu finden, der diesen Hash erzeugt. Das kannst Du nicht für alle möglichen Hashes vorausberechnen, siehe oben. Und ein Algorithmus, der zu einem gegebenen, beliebigen Hash in vertretbarer Zeit einen Klartext findet, der diesen Hash liefert, existiert meines Wissens auch nicht.
Brute-Force Attacken verwenden darum Passwort-Wörterbücher und damit ein Subset aller möglichen Hashes. Diese werden über Rainbow-Tables nochmal weiter verdichtet, so dass man ein vertretbares Datenvolumen im Terabyte-Bereich erhält.
D.h. ein MD5 gehashtes Passwort mit Zufallssalz und am besten noch Pfeffer ist nach wie vor nicht realistisch angreifbar, weil das Salz die Rainbow-Tables unwirksam macht und man für jeden Hash neu anfangen muss. Natürlich geht es besser, dafür ist ja SHA-2 gemacht. Die Hauptaufgabe ist es dort aber - meine ich - das Hashen vorsätzlich langsam zu machen, so dass man eben nicht per Hardware Millionen oder Milliarden Hashes pro Sekunde berechnen kann.
Gegen schwache Passwörter, die auch noch ungesalzen gehasht werden, hilft aber auch SHA-99 nicht.
Rolf
Hi Rolf,
stimmt, 10^38 ist doch noch eine beeindruckende Zahl.
Ich traue mich allerdings nicht zu behaupten, dass ein passendes Speichermedium, ggf. im Cluster, noch nicht existiert.
Als b+tree-Applikation ließe sich das bequem über mehrere Hosts mit (riesigen) (R)AIDS verteilen.
Jedenfalls gebe ich immer wieder die Empfehlung, bei MD5-Hashing zum Passwort auch dessen zu benutzende Länge in einer separaten Tabelle abzuspeichern und zu überprüfen. Das verringert die Chance beim M:1 (Passworte:Hash) Match, einen Treffer zu landen.
magst Du Raketes Beitrag mal so ergänzen, dass er ins Wiki passt?
Paranoide Grüße
localhorst
bei MD5-Hashing
MD5-Hashing sollte auf jeden Fall abgelöst werden. Das ist weit aus der Zeit.
Wenngleich Rolf recht damit hat, dass eine vollständige Rainbow-Table für MD5 nicht speicherbar sei, so wird Sie es dennoch bald sein.
Übrigens:
Die Schwäche von MD5 liegt darin, dass ein Hash relativ fix berechnet ist und dass es Kollisionsangriffe gibt (d.h. zwei Nachrichten mit gleichem Anfang liefern den gleichen Hash). Damit ist MD5 zum Signieren ungeeignet.
Ist so nicht zu halten. Die beiden (aus einem centos-Image hergestellten) Dateien
$ ls -lh /tmp/centos?
-rw------- 1 fastix fastix 4,2G Aug 28 16:55 /tmp/centos1
-rw------- 1 fastix fastix 4,2G Aug 28 16:55 /tmp/centos2
unterscheiden sich durch nur das letzte Byte ("1", "2")
$ md5sum < /tmp/centos1
43deec111a143a8a3fdfbf38c7804e15 -
$ md5sum < /tmp/centos2
45a97b054de3f5e8295d41170df51b09 -
Wenn bei MD5 zwei Nachrichten "mit gleichem Anfang" den gleichen Hash liefern würden sähe das anders aus. MD5 für Signatur bzw. Verifizierungszwecke zwecke ist aber dennoch inzwischen angreifbar.
dafür ist ja SHA-2 gemacht. Die Hauptaufgabe ist es dort aber - meine ich - das Hashen vorsätzlich langsam zu machen, so dass man eben nicht per Hardware Millionen oder Milliarden Hashes pro Sekunde berechnen kann.
Richtig ist, dass man irgendwann entdeckt, dass der SHA-1-Algo von der mitnormenden NSA geschwindigkeitsoptimiert wurde… Neben SHA2 und dessen Kindern (derzeit bis SHA512 gängig) soll die oben beschriebene Rundendreherei das Verfahren verlangsamen. Das geht in PHP mit password_hash() immerhin bis 2^30.
Standard (2^10 Runden):
<?php
$options = [];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
Test:
$ time php /tmp/test_standard.php
$2y$10$l5P.mHtjft91dz52vHmNqua7IiaquE06mrJoyv8C7MnapkneMmL9O
real 0m0,081s
user 0m0,073s
sys 0m0,008s
2^15 Runden:
<?php
# file: /tmp/test_15.php
$options = [
'cost' => 15,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
Test:
$ time php /tmp/test_15.php
$2y$15$zeOQVgaUtgZbyRC4A0tZRODSX7sXIozyGRo1oekEd7ejGmBTl75i6
real 0m1,912s
user 0m1,908s
sys 0m0,004s
(Maximum) 2^30 Runden:
<?php
#file: /tmp/test_30.php
$options = [
'cost' => 30,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
Test:
$ time php /tmp/test_30.php
# Nach über 1h noch kein Ergebnis.
# Ich lasse das gerade gegen das Update eines seit Februar
# nicht benutzten Windows antreten.
# Der Erfahrung nach dauert beides Stunden...
### Ups. Windows ist fertig!
Hallo Raketentester,
Wenngleich Rolf recht damit hat, dass eine vollständige Rainbow-Table für MD5 nicht speicherbar sei, so wird Sie es dennoch bald sein.
Ja, hab ich ja geschrieben. Mutmaßlich in 100 Jahren. Das ist zwar für IT eine kleine Ewigkeit, aber 1970 hat man sich ja auch so ein paar Merkwürdigkeiten überlegt. Zum Beispiel:
Und jetzt sind wir schon 50 Jahre weiter und in 18 Jahren fliegen garantiert ein paar Embedded-Systeme mit einem Overflow im time_t aus der Kurve. Insofern: Ja. Bald. Nicht zu unseren Lebzeiten, aber bald.
Wenn bei MD5 zwei Nachrichten "mit gleichem Anfang" den gleichen Hash liefern würden sähe das anders aus.
Das habe ich anders gemeint und unvollständig beschrieben. Es gibt für MD5 einen Angriff, der zu einer Nachricht mit gegebenem Anfang eine zweite Nachricht produziert, die den gleichen Anfang und den gleichen Hash hat. Zumindest habe ich die Beschreibung des Angriffs so verstanden.
Rolf
Jedenfalls gebe ich immer wieder die Empfehlung, bei MD5-Hashing zum Passwort auch dessen zu benutzende Länge in einer separaten Tabelle abzuspeichern und zu überprüfen.
Absolut kein guter Tipp. Grund: Der Angreifer kennt dann die Länge des Passworts, was einen Brute-Force-Angriff wesentlich (bis zu 50%, wenn er von "hinten" anfängt sogar um wesentlich mehr...) verkürzt.
Jedenfalls gebe ich immer wieder die Empfehlung, bei MD5-Hashing zum Passwort auch dessen zu benutzende Länge in einer separaten Tabelle abzuspeichern und zu überprüfen.
Absolut kein guter Tipp. Grund: Der Angreifer kennt dann die Länge des Passworts, was einen Brute-Force-Angriff wesentlich (bis zu 50%, wenn er von "hinten" anfängt sogar um wesentlich mehr...) verkürzt.
Verstehe ich nicht.
Woher soll der Angreifer die Länge des richtigen Passwortes kennen? Ganz im Gegenteil! Weil er die Länge des Passwortes nicht kennt, kann eher erkannt werden, wenn ein zum Hash passendes Passwort erraten wurde, dass aber nicht das richtige ist.
Wieviele Strings zum Hash passen, vermag ich nicht zu sagen, aber es sind garantiert mehrere, auch unterschiedlich lange.
LG
localhorst
Hallo localhorst,
wenn der Angreifer die Hashes kennt, dann hat er die DB geklaut. Und damit kennt er auch die Längen.
Rolf
Tach!
wenn der Angreifer die Hashes kennt, dann hat er die DB geklaut. Und damit kennt er auch die Längen.
Die Länge der Hashes ergibt sich aus dem Algorithmus. Die Länge des Passworts ist aber unbekannt. Es ist unüblich, diesen Wert extra abzulegen. Der ist für die Berechnung des Hashes nicht relevant und würde unnötigerweise einen Hinweis geben, wie das Brute Force einzuschränken geht.
dedlfix.
Hallo dedlfix,
du hast aber gelesen, worauf geantwortet wurde?
Rolf
Tach!
du hast aber gelesen, worauf geantwortet wurde?
Nicht alles. Ok, das Argument gegen ein Speichern der Länge kam schon. Trotzdem bleibt die Frage, wie soll an der Länge erkannt werden, ob es ein falsches Passwort ist, wenn die Länge aus Gründen besser nicht gespeichert wird?
Wenn man anhand der falschen Länge einen Angriff erkennen möchte, müsste man die Länge speichern und davon ausgehen, dass die Datenbank nicht gestohlen wurde. Aber wenn man davon ausgeht, dass sie vor Diebstahl sicher ist, könnte man gleich Klartext speichern. Sie per Hashing so zu gestalten, dass sie im Diebstahlfall unbauchbar ist, aber gleichzeitig Informationen zu speichern, die das Ermitteln des Passwortes erleichtern, da widersprechen sich die Interessenslagen. Angriffe muss man anders erkennen als an der Länge des probierten Strings.
dedlfix.
Tach!
du hast aber gelesen, worauf geantwortet wurde?
Nicht alles. Ok, das Argument gegen ein Speichern der Länge kam schon. Trotzdem bleibt die Frage, wie soll an der Länge erkannt werden, ob es ein falsches Passwort ist, wenn die Länge aus Gründen besser nicht gespeichert wird?
Wenn man anhand der falschen Länge einen Angriff erkennen möchte, müsste man die Länge speichern und davon ausgehen, dass die Datenbank nicht gestohlen wurde. Aber wenn man davon ausgeht, dass sie vor Diebstahl sicher ist, könnte man gleich Klartext speichern. Sie per Hashing so zu gestalten, dass sie im Diebstahlfall unbauchbar ist, aber gleichzeitig Informationen zu speichern, die das Ermitteln des Passwortes erleichtern, da widersprechen sich die Interessenslagen. Angriffe muss man anders erkennen als an der Länge des probierten Strings.
Ich schrieb extra: in einer eigenen Tabelle (aka Datenbank).
Aber jemand, der die Tabelle mit den Passworthashes stehlen kann, wird ohnehin (Voll)Zugriff aufs System haben.
IMHO ist die Behauptung, dass Datenbanken gestohlen wurden, nur eine Schutzbehauptung der Betreiber, weil sie die damit verbundenen Daten in Wirklichkeit teuer verkauft haben.
Mit einer separaten Speicherung der Passwortlänge oder besser eines zusätzlichen Hash-Verschlüsselungskeys kann man jedenfalls die Sicherheit erhöhen, wenn derjenige, der die Hashes hat nicht ohnehin gleich das Verifizierungsmodul patchen kann.
Welche (a)sozialen Plattformen verlangen eigentlich in geeigneten Abständen die Neusetzung des Passwortes? Und welche behandeln auch den Anmeldenamen als Geheimnis? Das machen mWn noch nicht einmal die Banken.
Alle theoretischen Ansätze sind aber obsolet, wenn die Pseudoprofis noch nicht einmal die einfachsten Möglichkeiten für Sicherheitsgewinn ausschöpfen.
LG
localhorst
Na? Guten Morgen!
Aber jemand, der die Tabelle mit den Passworthashes stehlen kann, wird ohnehin (Voll)Zugriff aufs System haben.
Einen Augenblick lang dachte ich, Du hättest verstanden.
IMHO ist die Behauptung, dass Datenbanken gestohlen wurden, nur eine Schutzbehauptung der Betreiber, weil sie die damit verbundenen Daten in Wirklichkeit teuer verkauft haben.
Dieser Meinung würde ich mich zumindest im Hinblick auf die inneliegende Allgemeingültigkeitsbehauptung niicht anschließen.
Pseudoprofis
Willst Du nun „geliebt werden“ oder um Dich hauen? Fürs „geliebt werden wollen“ sind einfache Sätze wie „Du hast Recht“ sehr hilfreich. Versuchs doch mal damit.
Na? Guten Morgen!
Aber jemand, der die Tabelle mit den Passworthashes stehlen kann, wird ohnehin (Voll)Zugriff aufs System haben.
Einen Augenblick lang dachte ich, Du hättest verstanden.
Dann bleib doch bitte wissenschaftlich und erkläre mir meinen Irrtum ;-)
IMHO ist die Behauptung, dass Datenbanken gestohlen wurden, nur eine Schutzbehauptung der Betreiber, weil sie die damit verbundenen Daten in Wirklichkeit teuer verkauft haben.
Dieser Meinung würde ich mich zumindest im Hinblick auf die inneliegende Allgemeingültigkeitsbehauptung nicht anschließen.
Aber die Möglichkeit eines solchen Zusammenhangs würdest Du in Betracht ziehen? Wieviel Prozent würdest Du wagen?
Pseudoprofis
Willst Du nun „geliebt werden“ oder um Dich hauen? Fürs „geliebt werden wollen“ sind einfache Sätze wie „Du hast Recht“ sehr hilfreich. Versuchs doch mal damit.
Ich will meine Erkenntnisse ständig hinterfragen dürfen. Auch öffentlich.
Ob ich dann dafür geliebt oder gehasst werden will, ist hier keine passende Frage. Ich würde mir nur wünschen, dass es auch Mitdenker gäbe, die bereit wären, ihre eigenen Gedankengänge offenzulegen, und sich nicht auf "best Practices" herauszureden.
LG
localhorst
Dann bleib doch bitte wissenschaftlich und erkläre mir meinen Irrtum ;-)
Also, was führt Dich zu der Vermutung, dass derjenige, der die Passwort-Hashes erlangen kann nicht auch an die zugeörigen Daten mit den Längen der ursprünglichen Passwörter kommt?
IMHO ist die Behauptung, dass Datenbanken gestohlen wurden, nur eine Schutzbehauptung der Betreiber, weil sie die damit verbundenen Daten in Wirklichkeit teuer verkauft haben.
Dieser Meinung würde ich mich zumindest im Hinblick auf die inneliegende Allgemeingültigkeitsbehauptung nicht anschließen.
Aber die Möglichkeit eines solchen Zusammenhangs würdest Du in Betracht ziehen? Wieviel Prozent würdest Du wagen?
Das kommt darauf an, ob Du unter „Betreiber“ ausschließlich die Eigentümer oder Geschäftsführer buchst oder auch Mitarbeiter.
Wenn Du Mitarbeiter mitzählst, dann darauf, ob Du Mitarbeiter von Drittfirmen mitzählst und zu guter Letzt, ob Du „einfach mal aus Rache irgendwo hochladen“ auch unter „in Wirklichkeit teuer verkauft“ buchst.
Nur Geschäftsführer und Betreiber? Dann tippe ich auf eine bei einem kleinen Bruchteil eines Prozents liegenden Zahl.
Pseudoprofis
Willst Du nun „geliebt werden“ oder um Dich hauen?
Ob ich dann dafür geliebt oder gehasst werden will, ist hier keine passende Frage.
Doch. Das ist es bei dem angeschlagenen Ton. Der ist beleidigend. wenn Du was sachliches hast, dann trag es sachlich vor.
Hallo Raketenpsychoedukationsbevollmächtigter,
Doch. Das ist es bei dem angeschlagenen Ton. Der ist beleidigend.
Du bist aber heute extrem dünnhäutig.
Bis demnächst
Matthias
Lieber Matthias,
Du bist aber heute extrem dünnhäutig.
dat darf dat.
Liebe Grüße
Felix Riesterer
L: Pseudoprofis
R: Willst Du nun „geliebt werden“ oder um Dich hauen? Fürs „geliebt werden wollen“ sind einfache Sätze wie „Du hast Recht“ sehr hilfreich. Versuchs doch mal damit.
L: Ob ich dann dafür geliebt oder gehasst werden will, ist hier keine passende Frage.
R: Doch. Das ist es bei dem angeschlagenen Ton. Der ist beleidigend.
M: Du bist aber heute extrem dünnhäutig.
Moin:
Wieso „dünnhäutig“?
Im Hinblick auf die GANZE Geschichte war das doch lediglich der Hinweis darauf, dass man sich mit solchen Worten keine Freunde macht – mithin lediglich Psychoedukation…
Hallo Raketenpsychoedukationbeauftragter,
lass mich mal eine andere Deutung versuchen. Wenn ein "Du hast Recht" für Dich Voraussetzung ist, dass Du dein Gegenüber magst (im Sinne von "geliebt werden"), ist das auch nicht unbedingt freundschaftsfördernd. Oder es fördert die falschen Freundschaften.
Bei den Pseudoprofis war ich mir übrigens gar nicht so sicher, ob damit Diskussionsteilnehmer oder "ungeschickte Hoster" im allgemeinen gemeint waren.
Den Pseudoprofi wird man übrigens am zuverlässigsten los, wenn man den behaupteten Sicherheitsgewinn qualifiziert als Pseudosicherheit belegt. Das habe ich zumindest versucht. Und ich bin, was Webhosting angeht, nichtmal ein Laie...
Rolf
Den Pseudoprofi wird man übrigens am zuverlässigsten los, wenn man den behaupteten Sicherheitsgewinn qualifiziert als Pseudosicherheit belegt.
Das hatte sowohl meine Raketenwenigkeit als auch Dedlfix getan. Statt sich aber mit dem Vortrag zu befassen wurde das Wort „Pseudoprofis“ in die Diskussion eingeführt.
Wenn ein "Du hast Recht" für Dich Voraussetzung ist, dass Du dein Gegenüber magst
Das war nur ein situationsgetriebener Vorschlag an denjenigen, der hier allen Ernstes die Speicherung eines MD5-Hashes des Passwortes und der Passwortlänge empfohlen hatte und nach der Darlegung, dass es sich um keine gute Idee handelte, mit dem selben Ernst die Fähigkeiten und die Glaubwürdigkeit der Vorredner durch den Gebrauch des Wortes „Pseudoprofis“ in Abrede stellte. Wer - bitte - nimmt denn nicht gern zur Kenntnis, dass sich derjenige, dessen Irrtum man zu korrigieren versucht, mit dem Cortrag auseinandersetzt und den Irrtum einsieht? Nichts anderes besagt mein Satz „Fürs „geliebt werden wollen“ sind einfache Sätze wie „Du hast Recht“ sehr hilfreich.“
Ich weiß auch nicht, wo Du hernimmst, dass ein "Du hast Recht" für mich Voraussetzung sei. Ich selbst bin bzw. war gar nicht „angepisst“ - aber solches Verhalten ist schlicht unmöglich. Ich wundere mich nur über das „dünnhäutig“. Mir selbst wurde gerade erst beigebracht, dass es im Hinblick auf die Entwicklung der Situation besser ist, solches Verhalten eben nicht schweigend zu übergehen sondern sondern umgehend zu monieren.
Und ich bin, was Webhosting angeht, nichtmal ein Laie...
Kommt in meinem Fall auf den Server an.
Hallo Raketenpsychoedukationbeauftragter,
Ich wundere mich nur über das „dünnhäutig“.
Ich konnte vorangegangenen Diskussion keinen Grund für deine Reaktion entnehmen. Für mich sah das extrem dünnhäutig aus. Wenn das eine falsche Wahrnehmung meinerseits war, ist ja alles gut.
Bis demnächst
Matthias
Hallo Raketenpsychoedukationbeauftragter,
ok, ich habe übertrieben und gestichelt. Und das auch noch vorsätzlich. Hätte ich nicht tun sollen, entschuldige bitte.
Ob wir localhorst nun noch überzeugt bekommen? Immerhin gibt's ja nun ein paar gute Argumente für die best practice.
Rolf
Issjaallesgut.
Hallo,
Doch. Das ist es bei dem angeschlagenen Ton. Der ist beleidigend. wenn Du was sachliches hast, dann trag es sachlich vor.
Ich bitte um Verzeihung, wenn mein Ton unangemessen gewesen war.
Ich kann die Stelle aber im Moment nicht erkennen. Es kann/sollte sich IMHO nur um ein Missverständnis handeln. Lass uns das doch bitte aus der Welt schaffen :-)
LG
localhorst
Hallo localhorst,
mutmaßlich geht es um
Pseudoprofis
und
herausreden
Aber ich fand auch, dass Jörg recht dünnhäutig war.
Du hast sicher recht, wenn Du sagst, dass die Hauptgefahrenquelle eines sicheren Systems innen liegt: bei den Admins, bei den Betreibern. Entweder, weil die existierenden Admins kriminell sind, oder weil sich ein Krimineller auf den Weg durch die Instanzen macht[1] und Admin wird.
Wenn ein Krimineller Zugang zur DB / zu den DBs bekommt, dann ist es innerhalb dieser Institution vorbei mit der Sicherheit. Da ist es in dieser einen Institution dann auch egal, ob die PW im Klartext, im MD5 Hash, mit separat abgelegter Längeninfo oder im Super-Duper-XKTZ-2099-Cryptohash gespeichert wurden.
Die Speicherung der PW-Länge in einer separaten DB ist Security by Obscurity: Man muss eine spezifische interne Information haben, um das PW rekonstruieren zu können. SbO ist aber nur Illusion, keine Security. Sie hilft Dir gegen inkompetente Einbrecher, oder gegen Code Injections, die irgendwie den PW Hash ermitteln. Und gegen kompetente Gegner hilft sie nichts, sondern macht ihnen, wie oben schon gesagt, das Leben leichter, weil nur noch Passwörter einer bestimmten Länge in Frage kommen.
Das Speichern eines separaten Hashs passiert ja eigentlich bei den neueren Methoden, wenn auch etwas anders gelöst. Da verwendet man ein Zufallssalz, wodurch vorausberechnete Angriffe sabotiert werden. Das funktioniert so gut, dass man das Salz nicht mal geheim halten muss. Elementare Anforderungen an Passwörter werden dadurch natürlich nicht obsolet, sie müssen schon eine gewisse Mindestkomplexität mitbringen.
Die Länge nützt nur in einem Fall: dass jemand von außen, durch Durchprobieren von Passwörtern auf dem Login-Form (per Script natürlich) versucht, das Passwort zu finden. Wenn es zwei PW gibt, die den gleichen Hash liefern, dann ist die Chance sehr klein, dass sie auch gleich lang sind.
Aber: Der Werteraum der Hashes, selbst bei MD5, ist so riesig, dass eine Hashkollision bei Passwörtern eigentlich nicht vorkommt. Deswegen ist der Zusatznutzen den Aufwand nicht wert. Da ist ein Fehlversuchszähler viel sinnvoller, der nach 5 oder 10 Versuchen die User-ID sperrt.
Wobei auch das überlegt sein muss - diesen Zähler hatten wir im carcassonne-online.info Forum. Und als jemand anfing, genau diesen Angriff gegen uns zu fahren, waren plötzlich alle User gesperrt, die Postings im offen lesbaren Bereich gemacht hatten. Da musste ich schnell die Loginseite gegen dumme Scripte härten (ein CSRF Token reichte).
Rolf
Ah, Entschuldigung an alle 68er, das sollte nicht andeuten dass jeder von euch ein Krimineller sei ↩︎
@@localhorst
Welche (a)sozialen Plattformen verlangen eigentlich in geeigneten Abständen die Neusetzung des Passwortes? Und welche behandeln auch den Anmeldenamen als Geheimnis? Das machen mWn noch nicht einmal die Banken.
Das erzwungene Neusetzen eines Passworts macht ein System nicht sicherer.
Im Gegenteil, es führt dazu, dass Nutzer sich ihre Passwörter nicht mehr merken können und deshalb auf verschiedenen Plattformen wiederverwenden, einfache Passwörter verwenden oder sich die Passwörter sogar aufschreiben.
Der Unsinn mit dem erzwungenen Neusetzen eines Passworts muss endlich mal aufhören. Neues Passwort, wenn das System gehackt wurde. Ansonsten nicht.
😷 LLAP
Hallo,
„Sag mir, wie Du Deine Maske trägst, und ich sage Dir, ob Du ein Idiot bist.“ —@Ann_Waeltin
in der Tat: Unterm Kinn getragen ist die Maske ungefähr so wirksam wie ein Fahrradhelm, der lässig am Ellbogen baumelt. Mit einem entscheidenden Unterschied: Beim Fahrradhelm hat der (Nicht-)Träger allein die Nachteile.
Live long and pros healthy,
Martin
@@Der Martin
„Sag mir, wie Du Deine Maske trägst, und ich sage Dir, ob Du ein Idiot bist.“ —@Ann_Waeltin
in der Tat: Unterm Kinn getragen ist die Maske ungefähr so wirksam wie ein Fahrradhelm, der lässig am Ellbogen baumelt. Mit einem entscheidenden Unterschied: Beim Fahrradhelm hat der (Nicht-)Träger allein die Nachteile.
Unter der Nase ist fast genauso bescheuert. Symbolbild
Mir kommt das Kotzen, wenn die Vollidioten heute durch Berlin ziehen.
😷 LLAP
Hallo,
in der Tat: Unterm Kinn getragen ist die Maske ungefähr so wirksam wie ein Fahrradhelm, der lässig am Ellbogen baumelt. Mit einem entscheidenden Unterschied: Beim Fahrradhelm hat der (Nicht-)Träger allein die Nachteile.
Unter der Nase ist fast genauso bescheuert. Symbolbild
das stimmt - aber so hab ich's in freier Wildbahn noch nicht gesehen. Dafür jemanden, der an der Haltestelle auf den Bus wartete, die Maske schon (korrekt) vor dem Gesicht hatte, die Unterkante von dem Ding aber alle paar Sekunden ein Stück hochgezogen hat, um an seiner Kippe zu ziehen.
Mir kommt das Kotzen, wenn die Vollidioten heute durch Berlin ziehen.
Ich hoffe, du musst dich nicht mit darunter mischen.
Live long and pros healthy,
Martin
Moin,
Gegen schwache Passwörter, die auch noch ungesalzen gehasht werden, hilft aber auch SHA-99 nicht.
du meinst Passwörter wie "hallo123"[1], oder Benutzername: Vorname, Passwort: Nachname?
Live long and pros healthy,
Martin
Gemäß einer Passwort-Statistik, die ich mal irgendwo gelesen habe, steht das tatsächlich unter den Top 3 der meistverwendeten. ↩︎
Eine Verschlüsselung braucht einen Schlüssel. Bei Base64 gips keinen.
Meinten Sie Gips schlüssel ?
Hallo Klaus,
der einfachste Versuch wäre für Dich, die Maildatei vom Skript als *.txt-Datei abspeichern zu lassen und sie dann erst einmal mit Notepad++ anzusehen.
Du kannst dann sehen, ob sie überhaupt den MIME-Regeln entspricht und auch mal hier posten, zur Not als Screenshot. Kann ja nicht lang sein.
Generell musst Du für die Abtrennung des Attachements die Boundaries suchen.
Das können wir Dir aber leichter erklären, wenn Du erst einmal die Testdatei gepostest hast.
LG
localhorst