unverständlicher Unterschied zwischen zwei Strings

[Linuchs]

Moin,

ein eingegebenes Passwort wird verglichen mit einem Passwort, das aus einer Textdatei gelesen wird.

Selbst dann, wenn ich das Passwort aus der Datei per Zwischenablage ins Passwortfeld übertrage, ergibt sich keine Gleichheit.

Ich zeige das eingegebene Passwort und den Dateiinhalt an:

$arr_in = array (
 'code'   =>( $_POST['code'] ) ? trim( $_POST['code'] ) : trim( $_GET['code'] )     // Abo bearbeiten oder loeschen
);
...
$code = trim( file_get_contents( "db/newsl.txt" ));
echo "<pre>[".$code."]==[".$arr_in['code']."]? [".(($code==$arr_in['code'])?"TRUE":"FALSE")."]</pre>";

Ausgabe:

[äÖüßñç]==[äÖüßñç]? [FALSE]

Programm arbeit im UTF-8 Modus, Datei wurde mit BOM geschrieben.

Nach verzweifelter Suche komme ich auf die Idee, dass es sich um zwei gleich aussehende Zeichensätze handeln könnte:

  echo "<pre>";
  for ( $i=0; $i<strlen($code); $i++ ) {
    echo ord($code[$i])." ";
  }
  echo "<br>";
  for ( $i=0; $i<strlen($arr_in['code']); $i++ ) {
    echo ord($arr_in['code'][$i])." ";
  }
  echo "</pre>";

und tatsächlich:

239 187 191 195 164 195 150 195 188 195 159 195 177 195 167 
195 164 195 150 195 188 195 159 195 177 195 167 

wie ist das möglich? Darf die Textdatei nicht mit BOM geschrieben werden? Und warum unterdrückt echo die drei führenden BOM-Bytes?

fragt Linuchs

[dedlfix]

Tach!

wie ist das möglich? Darf die Textdatei nicht mit BOM geschrieben werden? Und warum unterdrückt echo die drei führenden BOM-Bytes?

Die BOM ist ein Zeichen, oder auch drei, wenn man die Datei als ISO-8859-x liest. Ein oder drei Zeichen zu haben oder nicht zu haben ist halt ein Unterschied. echo unterdrückt nichts. echo zeigt auch nichts an. Da sind noch mehr Komponenten zwischen echo und den Pixeln auf dem Bildschirm, die dafür sorgen, dass die BOM nicht zu sehen ist. Intentionsgemäß ist sie unsichtbar.

dedlfix.

[Der Martin]

Hallo,

wie ist das möglich? Darf die Textdatei nicht mit BOM geschrieben werden?

doch, aber man darf diese BOM dann nicht als Teil des Nutzinhalts betrachten.

Und warum unterdrückt echo die drei führenden BOM-Bytes?

Tut es nicht. Aber die BOM gilt als nicht druckbares Zeichen, hat also keine visuelle Repräsentation.

Die BOM ist ein Zeichen, oder auch drei, wenn man die Datei als ISO-8859-x liest. Ein oder drei Zeichen zu haben oder nicht zu haben ist halt ein Unterschied. echo unterdrückt nichts. echo zeigt auch nichts an. Da sind noch mehr Komponenten zwischen echo und den Pixeln auf dem Bildschirm, die dafür sorgen, dass die BOM nicht zu sehen ist. Intentionsgemäß ist sie unsichtbar.

Allerdings hätte ich erwartet, dass trim() auch eine BOM entfernt.

Ciao,
 Martin

[dedlfix]

Tach!

Allerdings hätte ich erwartet, dass trim() auch eine BOM entfernt.

Ich nicht, denn trim() ist keine UTF-8-fähige Funktion und sieht da lediglich drei Zeichen, die nicht auf seiner Liste der Whitespaces stehen.

dedlfix.

[Der Martin]

Hallo,

Allerdings hätte ich erwartet, dass trim() auch eine BOM entfernt.

Ich nicht, denn trim() ist keine UTF-8-fähige Funktion und sieht da lediglich drei Zeichen, die nicht auf seiner Liste der Whitespaces stehen.

hmm, wo er Recht hat ...

Ciao,
 Martin

[Rolf B]

Hallo Linuchs,

PHP ist im Prinzip nicht Unicode-fähig. Die Behandlung von Unicode-Strings wurde mit den mb_-Funktionen nachgerüstet, und die Datenbanktreiber können da sicherlich auch etwas beitragen, aber im Standardverhalten betrachtet PHP Strings als Bytefolgen.

file_get_contents gehört dazu, es weiß nichts vom Encoding und liefert Dir daher das BOM als Teil des Passworts mit.

Das BOM ist aber nicht nur das Byte Order Mark, sondern auch ein Unicode-Codepunkt mit der Bedeutung "Nullbreite Leerstelle". Deswegen zeigt der Browser dort eine Leerstelle mit einer Breite von 0 Pixeln an.

Da ein BOM nur schwierig visuell wahrnehmbar ist, besteht die beste Lösung darin, die von file_get_contents gelesene Bytefolge auf ein führendes BOM zu prüfen und das BOM bei Bedarf zu entfernen. Aber Vorsicht, BOM ist nicht gleich BOM. Was Du hier gefunden hast, ist das UTF-8 BOM. Es gibt noch 10 andere, die aber hoffentlich für Dich irrelevant sind. Es könnte auch interessant sein, wenn Du ein UTF-8 BOM in der Textdatei zwingend voraussetzt. Denn dann hast Du eine Zusicherung, dass diese Textdatei auch UTF-8 codiert ist, statt z.B. ISO-8859-15.

Und natürlich funktioniert das alles nur, wenn Du auch vom Browser einen UTF-8 String bekommst, aber das solltest Du über das Encoding der gesendeten HTML Seite sicherstellen können.

Rolf

[dedlfix]

Tach!

Es könnte auch interessant sein, wenn Du ein UTF-8 BOM in der Textdatei zwingend voraussetzt. Denn dann hast Du eine Zusicherung, dass diese Textdatei auch UTF-8 codiert ist, statt z.B. ISO-8859-15.

Es ist lediglich ein Indiz. Ob der Rest fehlerfrei gemäß UTF-8 kodiert ist, kann eine BOM allein nicht sicherstellen.

dedlfix.

[Rolf B]

Hallo dedlfix,

deswegen verwendete ich den Begriff "Zusicherung" und nicht "Garantie". Versprechen können gebrochen, und Zusicherungen missverstanden werden.

Ich kann Dir jederzeit zusichern, dass der Himmel heute blau ist, aber deswegen kannst Du trotzdem im Regen stehen (weil ich nämlich von Vinobrandt Himmel, stadtbekannter Säufer, geredet habe)

Rolf

[dedlfix]

Tach!

deswegen verwendete ich den Begriff "Zusicherung" und nicht "Garantie". Versprechen können gebrochen, und Zusicherungen missverstanden werden.

Ich habe bereits die Wortwahl missverstanden. Eine Zusicherung ist für mich ein Synonym zu Garantie. "Sicher" oder eine "Sicherung" ist für mich etwas, das man als "wird gegeben sein" hinnehmen kann. Lediglich unvorhersehbare Dinge können der Erfüllung im Wege stehen. Fehlerhafte Kodierungen sind aber keine Seltenheit und damit vorhersehbar, also etwas, mit dem man rechnen muss.

Aber egal, wie man es nennt, die BOM ist kein Ruhekissen.

dedlfix.

[Gunnar Bittersmann]

@@Rolf B

Das BOM ist aber nicht nur das Byte Order Mark, sondern auch ein Unicode-Codepunkt mit der Bedeutung "Nullbreite Leerstelle".

Wobei aber die Verwendung von U+FEFF als zero-width no-break space (ZWNBSP) deprecated ist.

LLAP 🖖

[MudGuard]

Hi,

ein eingegebenes Passwort wird verglichen mit einem Passwort, das aus einer Textdatei gelesen wird.

Das macht man aber nicht. Man speichert nicht das Paßwort, sondern einen (gesalzenen) Hash davon.

Wenn dann das Paßwort eingegeben wird, bildet man (mit demselben Salz) den Hash, und vergleicht dann die beiden Hashes.

Da Hashwerte üblicherweise nur Zeichen aus US-ASCII benutzen, fällt das UTF-8-BOM-Problem dann weg - einfach keinen in die Datei schreiben, braucht ja keine UTF-8-Codierung zu sein ...

cu,
Andreas a/k/a MudGuard

[Felix Riesterer]

Lieber MudGuard,

Das macht man aber nicht. Man speichert nicht das Paßwort, sondern einen (gesalzenen) Hash davon.

prinzipiell gebe ich Dir Recht. Es kann aber bei sehr kleinen Projekten einen Sinn haben, die z.B. keine Datenbank nutzen und auch ansonsten sehr simpel gestrickt sind.

An dieser Stelle erscheint es mir, als hätte @Linuchs ein kleines Tool für ausschließlich seine Zwecke mit sehr überschaubarem Nutzerkreis und Funktionalität geschaffen. Ob man hier gleich professionelle Maßstäbe an die Sicherheit der Passwortspeicherung ansetzen sollte...? Schon klar, währet den Anfängen - daher hat Dein Posting seine unzweifelhafte Berechtigung. Aber berücksichtigt es auch den Rahmen?

Liebe Grüße

Felix Riesterer

[Auge]

Hallo

Das macht man aber nicht. Man speichert nicht das Paßwort, sondern einen (gesalzenen) Hash davon.

prinzipiell gebe ich Dir Recht. Es kann aber bei sehr kleinen Projekten einen Sinn haben, die z.B. keine Datenbank nutzen und auch ansonsten sehr simpel gestrickt sind.

Der Speicherort der Passwörter hat nichts mit dem Speicherformat (Klartext versus Hash) zu tun.

An dieser Stelle erscheint es mir, als hätte @Linuchs ein kleines Tool für ausschließlich seine Zwecke mit sehr überschaubarem Nutzerkreis und Funktionalität geschaffen. Ob man hier gleich professionelle Maßstäbe an die Sicherheit der Passwortspeicherung ansetzen sollte...?

Ja. Sein Server kann genauso geknackt werden, wie jeder andere.

Tschö, Auge

[MudGuard]

Hi,

prinzipiell gebe ich Dir Recht. Es kann aber bei sehr kleinen Projekten einen Sinn haben, die z.B. keine Datenbank nutzen und auch ansonsten sehr simpel gestrickt sind.

Häh? Ich hab doch gar nichts gegen die Speicherung in einer Datei gesagt. Nur dagegen, die Paßwörter direkt statt eines Hashs zu speichern.

Es geht niemanden außer dem User selbst etwas an, welches Paßwort der User benutzt - auch nicht den Betreiber der Seite oder den Server-Admin oder wer sonst noch den Speicherort der Zugangsdaten besichtigen kann.

An dieser Stelle erscheint es mir, als hätte @Linuchs ein kleines Tool für ausschließlich seine Zwecke mit sehr überschaubarem Nutzerkreis und Funktionalität geschaffen.

Selbst dann: das konkrete Paßwort darf nicht lesbar sein. Viele User nutzen ein Paßwort für viele Zwecke … (sollten sie nicht tun, aber die Realität sieht doch anders aus)

Ob man hier gleich professionelle Maßstäbe an die Sicherheit der Passwortspeicherung ansetzen sollte...? Schon klar, währet den Anfängen

"wehret"!

Und irgendwann wird das Projekt ein bißchen größer und der Nutzerkreis wächst, oder die Login-Logik wird für ein weiteres Projekt wiederverwendet …

• daher hat Dein Posting seine unzweifelhafte Berechtigung. Aber berücksichtigt es auch den Rahmen?

ja.

cu,
Andreas a/k/a MudGuard