Passwortkodierung bei Firebird 3 nicht abwärtskompatibel?
Verfasst: So 5. Jul 2020, 19:39
Hallo zusammen,
ich habe ein seltsames Phänomen bei bestimmten Passwörtern (connect scheitert) und mich würde interessieren, ob ihr das reproduzieren könnt.
Setup: ein Webserver (recht aktueller xampp apache auf win10), der mit einem Firebird 3.0.4 und einem Firebird 2.5.9 Server reden muss. Entsprechend bekommt er eine 3.0.4er fbclient.dll ins apache/bin-Verzeichnis, da er ja auch den 3er Server ansprechen muss. Eigentlich müsste der Effekt aber bei jeder Art Client auftreten, nicht nur bei einem Webserver.
Das Testpasswort ist °!"§$%&/
also einmal auf der Tastatur die ersten 8 Zeichen mit Shift-Taste. Zwei davon, das Grad-Symbol und das Paragraphenzeichen liegen oberhalb Ascii 127.
Testskript:
Führe ich das mit der regulären 3.0.4er fbclient.dll aus, gibt es "Your user name and password are not defined. Ask your database administrator to set up a Firebird login. " Gebe ich dem apachen eine 2.5.9er fbclient.dll, klappt das connect. Offensichtlich kodieren die beiden fbclients das Passwort unterschiedlich.
Der Effekt müsste sich auch mit anderen client-Anwendungen reproduzieren lassen. Der connect-Zeichensatz scheint bei dem Vorgang egal zu sein. Die Zeichenkodierung der Skriptdatei ist utf8, und damit auch das Passwort-Literal.
Also wenn ihr eine Idee habt ... immer her damit, ich leg mir gerade die Karten
Grüße, Volker
ich habe ein seltsames Phänomen bei bestimmten Passwörtern (connect scheitert) und mich würde interessieren, ob ihr das reproduzieren könnt.
Setup: ein Webserver (recht aktueller xampp apache auf win10), der mit einem Firebird 3.0.4 und einem Firebird 2.5.9 Server reden muss. Entsprechend bekommt er eine 3.0.4er fbclient.dll ins apache/bin-Verzeichnis, da er ja auch den 3er Server ansprechen muss. Eigentlich müsste der Effekt aber bei jeder Art Client auftreten, nicht nur bei einem Webserver.
Das Testpasswort ist °!"§$%&/
also einmal auf der Tastatur die ersten 8 Zeichen mit Shift-Taste. Zwei davon, das Grad-Symbol und das Paragraphenzeichen liegen oberhalb Ascii 127.
Testskript:
Code: Alles auswählen
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>testconnect</title>
</head>
<body>
<?php
// testconnect
$uid = 'tester';
$pw = '°!"§$%&/';
$pw = mb_convert_encoding($pw, 'ISO-8859-1', 'UTF-8');
$hex = '';
for ($i = 0; $i < strlen($pw); $i++) {
$ord = ord($pw[$i]);
$hexCode = dechex($ord);
$hex .= substr('0' . $hexCode, -2);
}
echo $hex;
// b0 21 22 a7 24 25 26 2f
// bzw ohne umkodierung nach latin1
// c2 b0 21 22 c2 a7 24 25 26 2f
$dec = array();
for ($i = 0; $i < strlen($pw); $i++) {
$dec[] = ord($pw[$i]);
}
echo '<pre>'; print_r($dec); echo '</pre>';
echo '<br>';
echo "connecte als $uid ..." . '<br>';
$conn = ibase_connect(<db-alias>, $uid, $pw, 'ISO8859_1', 0, 3); // <db-alias> ist eine 2.5er DB
var_dump($conn);
echo '<br>';
if ($conn)
echo 'connected';
else {
echo 'not connected<br>';
echo ibase_errmsg();
}
?>
</body>
</html>
Der Effekt müsste sich auch mit anderen client-Anwendungen reproduzieren lassen. Der connect-Zeichensatz scheint bei dem Vorgang egal zu sein. Die Zeichenkodierung der Skriptdatei ist utf8, und damit auch das Passwort-Literal.
Also wenn ihr eine Idee habt ... immer her damit, ich leg mir gerade die Karten
Grüße, Volker