perl blowfish gebax

Remélem valaki tud segíteni, mert megmarom magam...

Van nekem saját használatra egy kis perl cgi cucc, nekem egy jelszóadatbázis. Rövid leírás, jelszó, mesterkulccsal meg blowfish-sel kódolja, beteszi mysql-be. Ha kell, mesterkulcsot megadom, dekódolja, kész. Eddig ment.
Namost a legutóbbi frissítés óta ez nem működik. Egy krix-krax jön vissza mindre. Tuti jó a mesterkulcs, az olyan, hogy csak akkor nem fogom már tudni, ha átmegy rajtam a villamos.

Aztán eszembe jutott, hogy még nem is frissítettem a chroot-ot (tehát ezekkel a libekkel (libmysql, perl libek), amivel korábban ment, most nem megy), jk_init, megcsinálta, ugyanúgy nem megy.

Érdekes még, hogy ha hozzáadok most egy újat, hozzáadja. De dekódolni azt se bírja, az is krix-krax.

A kód baromi egyszerű, ez a dekódolás (már kivettem egy külön fájlba, így próbálgattam, de persze így se jó):


#!/usr/bin/perl

use Crypt::CBC;
use DBD::mysql;

do "config.cgi";

$desc = 'akarmi';


                        $connect = DBI->connect("dbi:mysql:$dbname:$dbhost", $dbuser, $dbpass);
                        $pwquery = "SELECT pass FROM pwdb WHERE description='$desc'";
                        $handle = $connect->prepare($pwquery);
                        $handle->execute() || print "Adatbázis hiba: $DBI::errstr\n";
                        @row = $handle->fetchrow_array;
                        $encodedpass = $row[0];
                        $handle->finish;
                        $connect->disconnect;

                        $cipher = Crypt::CBC->new( -key    => 'mesterkulcs',
                                                   -cipher => 'Blowfish'
                                                 );
                        $pass = $cipher->decrypt($encodedpass);

print $pass . "\n";

Ez meg a kódolás és berakás:


                        $cipher = Crypt::CBC->new( -key    => $masterkey1,
                                                   -cipher => 'Blowfish'
                                                 );
                        $encodedpass = $cipher->encrypt($newpass1);

                        $connect = DBI->connect("dbi:mysql:$dbname:$dbhost", $dbuser, $dbpass);
                        $insert = "INSERT INTO pwdb (description,pass,owner) VALUES (\"$description\",\"$encodedpass\",$uid)";
                        $handle = $connect->prepare($insert);
                        $handle->execute() || print "Adatbázis hiba: $DBI::errstr";
                        $handle->finish;
                        $connect->disconnect;

                        $description = "";

Eddig ment, mi történhetett? Egy nyomorult blowfish nem ugyanúgy működik már, mint pár verzióval ezelőtt? Kezdek ideges lenni...

Hozzászólások

Hozzáadok egyet, description 'akarmi', jelszó 'asd123', mesterkulcs 'mk', beteszi.
Aztán megnézem az 'akarmi'-t, megadom az 'mk' kulcsot, erre: '��+Wz�'
--
Discover It - Have a lot of fun!

Mit frissítettél mire? Konkrétan a perlnek, a moduloknak, libc-nek, stb. mi volt a verziószáma a frissítés előtt, ill. után? Ezeket tudva talán el lehetne indulni a changelogok alapján, és kibányászni, hogy mi, hol romlott el.

Esetleg valamilyen karakterkódolási probléma nem jöhet szóba? Vagy az összes jelszó, mesterkulcs (7 bites) ASCII?

Dist upgrade-t csináltam hétvégén opensuse 11.0(->11.1->11.2)->11.3 a kis home szerveremen...
Lement minden hiba nélkül, és minden más megy is gond nélkül. Hát a jóisten se gondolta, hogy pont ez nem fog... Ez kb. olyan, mintha mondjuk az md5sum ugyanarra az inputra már nem azt a hasht adná, mint régen...
11.0-on: libc 2.8 és perl 5.10.0
11.3-on: libc 2.11.2 és perl 5.12.1

szerk: nem tudom milyen kódolás problémára gondolsz, minden UTF8 elvileg, a mysql, a cgi kódolása, az apache, minden... Ékezetes karakterek, japán jelek, kanji karakterek, cirill betűk stb. pedig se a jelszavakba, se a mesterkulcsba nincsen.
--
Discover It - Have a lot of fun!

"Ékezetes karakterek, japán jelek, kanji karakterek, cirill betűk stb. pedig se a jelszavakba, se a mesterkulcsba nincsen."

Igen, látom, ha az asd123 se megy, akkor ez kiesett.

Esetleg a perlmonks-on próbáld meg feltenni a kérdést, hátha ott jobban értenek hozzá.

szerk: a Crypt::CBC doksijában láttam az alábbit:

IMPORTANT NOTE: Versions of this module prior to 2.17 were incorrectly using 8-byte IVs when generating the "randomiv" style of header, even when the chosen cipher's blocksize was greater than 8 bytes. This primarily affects the Rijndael algorithm. Such encrypted data streams were not secure. From versions 2.17 onward, Crypt::CBC will refuse to encrypt or decrypt using the "randomiv" header and non-8 byte block ciphers. To decrypt legacy data encrypted with earlier versions of the module, you can override the check using the -insecure_legacy_decrypt option. It is not possible to override encryption. Please use the default "salt" header style, or no headers at all.

Sajnos az "-insecure_legacy_decrypt" se segített.
És azért is esik ki, mert az asd123-at vagy bármi mást ha most adom hozzá, azt elvileg már akkor az új encrypt-tel teszi be, amit simán enélkül a kapcsoló nélkül ki is tudna szedni decrypt-tel. De azt se lesz jó...

szerk.: Megnéztem pár olyan jelszót, amit fejből is tudok... Hát most a crypt ugyanazzal a mesterkulccsal teljesen mást ad mindegyiknél, mint ami az sqlbe van...
--
Discover It - Have a lot of fun!

Megnéztem pár olyan jelszót, amit fejből is tudok... Hát most a crypt ugyanazzal a mesterkulccsal teljesen mást ad mindegyiknél, mint ami az sqlbe van

Ha megnézed a CBC-t, akkor látod, hogy egy inicializációs vektorral indul. Ez nem blowfish-függő, az csak a blokk-sifrírozó, itt a cipher haszálati módját jelentő CBC-ről van szó.

Feltéve, hogy a plaintext-ed K db egész blokkból áll, úgy a ciphertext-ed (a CBC kimenete) K+1 db egész blokkból fog állni, mivel az IV-t is el kell tárolni ahhoz, hogy a dekódolást be lehessen indítani. Az IV-nek nem kell titkosnak lennie, csak az a fontos, hogy (azonos kulcs esetén) egyedi legyen. (Ha az input nem egész számú blokkból áll, az sem gond, de ez itt most mellékes.)

Szerintem valahol az IV tárolása és visszaolvasása körül lesz a probléma.

... Nézem a doksit, jó eséllyel ez lesz az: The "salt" header is now the default as of Crypt::CBC version 2.17. In all earlier versions "randomiv" was the default. Vagyis feltételezhetően a

Crypt::CBC->new()

-ba bele kellene raknod egy ilyet is:

-header => 'randomiv'

Lásd a SYNOPSIS-ban a RANDOMIV-compatible mode-ot!

Csak a kódolás/dekódolás megy? Mármint adatbázisba berakás/kivétel nélkül?

A MySQL karakterkódolása nem változott/kavar be?

Nos, de... Ez volt a probléma. Minden UTF-8 volt... Kivéve az adatbázis lett default latin1 encodinggal kreálva. Az OK, hogy benne az adatok UTF8. De volt már ebből máskor is probléma frissítésnél (mármint nem konkrétan ennél, hanem más szerveren pl. hostolt weboldalaknál egy-egy dist upgrade után, ugyanezen okból). Ott is hiába csináltál az újjal bármit, a megfelelő kódolással már nem tudtad kivenni az adatot.
Namost, van nekem még 11.0 szerverem, ott beimportáltam a mentést, áttettem a cgi-t, és ott működött rendben, ahogy régen... Úgyhogy kimentettem mindent, kreáltam új adatbázist, immár azt is encoding UTF-8 és collate ut8_general_ci-vel. Beletettem shellből futatott gyorsan legyártott importáló cgi-vel. Viszont még valami gubanc van, mert shellből ki tudom olvasni jól, de webről nem... Szóval hiába UTF8 minden, még valami gond van.
(Ha viszont a webről teszek be egy új elemet, azt se a webről, se shellből nem tudom rendesen kiolvasni)
--
Discover It - Have a lot of fun!

Először talán a klasszikus "árvíztűrő tükörfúrógép"-et kellene tudni mindenünnen írni-olvasni. Perl-es kapcsolódást nem ismerem, nem lehet ott a kliens karakterkódolását megadni (MySQL kapcsolódásnál)?

Mert szerintem az lesz a baj, hogy a konzolod UTF8-as, a webnél meg ki tudja...

GThomas


mysql> charset utf8;
Charset changed
mysql> set character_set_server = utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set collation_server = utf8;
ERROR 1273 (HY000): Unknown collation: 'utf8'
mysql> set collation_server = utf8_general_Ci;
Query OK, 0 rows affected (0.00 sec)

mysql> set collation_server = utf8_general_ci;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_database = utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set collation_database = utf8_general_ci;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_client = utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_connection = utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set collation_connection = utf8_general_ci;
Query OK, 0 rows affected (0.00 sec)

mysql> set character_set_results = utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set names utf8 collate utf8_general_ci;
Query OK, 0 rows affected (0.00 sec)

Továbbra sem jó.
--
Discover It - Have a lot of fun!

szerintem sokat dobna a dolog megbízhatóságán, ha a szöveges mezőtípusokba szöveges adatot raknál, és nem bináris maszlagot...

Ohh bakker. Amit csináltam visszaimportáló script, az stdinről olvassa be a mesterkulcsot...

$masterkey = <STDIN>

És ebbe benne van a \n is... No comment, user error.
--
Discover It - Have a lot of fun!