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...
- 1720 megtekintés
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!
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
"É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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
"11.3-on: libc 2.11.2 és perl 5.12.1"
Jujj... par dolog csak nemreg lett stabil 5.10-es Perlen, es mar itt az 5.12? Akkor most elkezdek aggodni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Akkor próbáld azt, hogy a kódolás eredményéül kapott bináris adatot átkódolod sima ASCII-ba, pl base64 vagy pack "h*", és úgy teszed be az adatbázisba.
- A hozzászóláshoz be kell jelentkezni
Igen, most ezt csináltam. Vissza a mező típusa text-re, base64-gyel tettem be.
Így sem jó :(
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Az apachenak default az UTF-8, ez nincs módosítva. A cgi meg headerbe ezt küldi:
print "Content-Type: text/html; charset=UTF-8\n\n"
Tehát ez is biztos UTF-8...
DBD::mysql-nek meg én is kerestem ilyen encoding megadást, de nem nagyon találtam.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
http://www.php-blog.hu/php-magyar-kezikonyv/function.mysql-set-charset…
ill. bocs, nem php:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
(SET NAMES)
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Regen hasznaltam mar perl-t, de ez segithet?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Mysql 3 meg 4? Mikor volt már az?...
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Esetleg ha kiprobalnad... Ugyanis ez a resze pont hogy jo esellyel megy mysql 5 meg 6-tal is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
igen, valószínű ez is benne volt a dologba.
De most amikor újracsináltam, már mediumblob lett a mező típusa...
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
IV ugyanaz? Adatbázisban biztos csak 1 sor van, jót veszel elő?
- A hozzászóláshoz be kell jelentkezni
Az IV nem tudom, hogy ugyanaz-e.
Igen, biztos jót vesz ki.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni