Непоследователни резултати от криптиране/декриптиране

Имам напълно объркващи резултати при криптиране/декриптиране. Имам два различни низа, които трябва да кодирам и по-късно да декодирам, като криптираният низ се съхранява в база данни на MySQL между тях. Първият от тези низове излиза добре. Вторият обаче винаги се връща от дешифриране със стойността FALSE. Премахнах всички несъществени фактори и директно предавам стойност на "тест" в обикновен текст и на двете процедури за криптиране. Отново първият се връща правилно (като "test"), вторият се връща като "false").

Удрям си главата в стената, опитвайки се да разбера какво правя грешно. Използвам една и съща парола и същата сол и в двата файла. Как е възможно едното да работи, а второто да не???

Една следа: ако поставя този код в един php файл и прескоча базата данни, всичко работи добре. Не знам какво да правя с това, но поне е интересно.

Ето кода. Процедурата за криптиране/декриптиране идва от потребителска публикация на php сайта за mcrypt. Може ли някой да го види? Сигурно е нещо глупаво.

setValues.php

$encrypted_email_pw = encrypt("test", $password);
$encrypted_default_pw = encrypt("test", $password);

$sql = "UPDATE Settings 
        SET email_password='$encrypted_email_pw', 
            default_pw='$encrypted_default_pw'
        WHERE id='$id'";
$result = mysql_query($sql);

getValues.php

$sql = "SELECT * FROM Settings";
$result = mysql_query($sql);
$row = mysql_fetch_array($result); //there is only one row in this table

$decrypted_email_pw = decrypt($row['email_password'], $password);
$decrypted_default_pw = decrypt($row['default_pw'], $password);

echo $decrypted_email_pw . " | " . $decrypted_default_pw;
//output:  test | false
die();

crypto.php

<?php

    function encrypt($decrypted, $password, $salt='6rVDB?zKe6batB+k') { 

        // Build a 256-bit $key which is a SHA256 hash of $salt and $password.
        $key = hash('SHA256', $salt . $password, true);

        // Build $iv and $iv_base64.  
        // We use a block size of 128 bits (AES compliant) and CBC mode.  
        // (Note: ECB mode is inadequate as IV is not used.)
        srand(); $iv = mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC), MCRYPT_RAND);
        if (strlen($iv_base64 = rtrim(base64_encode($iv), '=')) != 22) return false;

        // Encrypt $decrypted and an MD5 of $decrypted using $key.  
        // MD5 is fine to use here because it's just to verify successful decryption.
        $encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $decrypted . md5($decrypted), MCRYPT_MODE_CBC, $iv));

        // We're done!
        return $iv_base64 . $encrypted;
    } 

    function decrypt($encrypted, $password, $salt='6rVDB?zKe6batB+k') {

        // Build a 256-bit $key which is a SHA256 hash of $salt and $password.
        $key = hash('SHA256', $salt . $password, true);

        // Retrieve $iv which is the first 22 characters plus ==, base64_decoded.
        $iv = base64_decode(substr($encrypted, 0, 22) . '==');

        // Remove $iv from $encrypted.
        $encrypted = substr($encrypted, 22);

        // Decrypt the data.  
        // rtrim won't corrupt the data because the last 32 characters are the md5 hash; 
        // thus any \0 character has to be padding.
        $decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, base64_decode($encrypted), MCRYPT_MODE_CBC, $iv), "\0\4");

        // Retrieve $hash which is the last 32 characters of $decrypted.
        $hash = substr($decrypted, -32);

        // Remove the last 32 characters from $decrypted.
        $decrypted = substr($decrypted, 0, -32);

        // Integrity check.  If this fails, either the data is corrupted, or the password/salt was incorrect.
        if (md5($decrypted) != $hash) return false;

        return $decrypted;
    }

?>

person AndroidDev    schedule 13.08.2013    source източник
comment
Не използвайте фиксирана сол.   -  person SLaks    schedule 14.08.2013
comment
Искате да кажете, че това обяснява противоречивите резултати?   -  person AndroidDev    schedule 14.08.2013
comment
Първо опитайте да пропуснете изцяло стъпката на базата данни и вместо това опитайте да прехвърлите данните от криптиране към декриптиране в самия скрипт, без да преминавате към SQL или някъде другаде. Изглежда тривиално, но първо трябва да знаете дали базата данни влияе на резултата или има нещо нередно с работата на самата библиотека за шифроване.   -  person BrianH    schedule 14.08.2013
comment
@usr55410: Не; това не е така.   -  person SLaks    schedule 14.08.2013
comment
Току-що редактирах публикацията си, за да отбележа, че съм пробвал това. Работи добре без db. Тествах щателно съхранението и извличането от db и получавам резултатите, които бих очаквал. Не мога да разбера защо db има някаква роля в това.   -  person AndroidDev    schedule 14.08.2013


Отговори (1)


Проверихте ли двете колони в таблицата с настройки? Имат ли едни и същи типове данни? И сигурни ли сте, че методите encrypt() и decrypt() работят правилно?

След като направите това да работи, трябва да обмислите използването на произволно генерирана сол за всяка парола и да съхранявате солта в таблицата заедно с паролата.

person Mark Lowe    schedule 13.08.2013
comment
Това беше. Една от колоните ми беше varchar(100), а другата беше varchar(50). Благодаря! - person AndroidDev; 14.08.2013
comment
Това е много интересен резултат - и такъв, който не очаквах. Гласуване за въпроса и отговора! - person Floris; 14.08.2013