[Zend Framework] Waarom clone Zend_Db_Select object?

[nika]

Ik ben bezig met een extensie van Zend_Auth_Adapter_DbTable die werkt met salted hashes.

Nu kom ik in de originele Zend_Auth_Adapter_DbTable code het volgende tegen.

code:

protected function _authenticateCreateSelect()
{
...
$dbSelect = clone $this->getDbSelect();
        $dbSelect->from($this->_tableName, array('*', $credentialExpression))
                 ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' = ?', $this->_identity);
...
}

$this->getDbSelect retourneert uiteindelijk niet anders dan een nieuw Zend_Db_Select object.

Mijn vraag: waarom zou je dit nieuwe object vervolgens clonen en niet gewoon het object zelf gebruiken?

[HuHu]

Omdat één regel later een "return $dbSelect;" staat en men blijkbaar niet wil dat het originele $dbSelect object buiten de klasse komt. Zend_Auth_Adapter_DbTable gebruikt namelijk altijd hetzelfde object en door een kopie te returnen voorkom je dat iemand anders het object van buiten de klasse kan aanpassen en zo de werking van de klasse kan beïnvloeden.

[ Voor 7% gewijzigd door HuHu op 02-09-2010 10:40 ]

[nika]

Duidelijk verhaal.

Aan de andere kant is de function protected dus komt het return object niet buiten de klasse terecht (volgens mij ook niet later in de chain).

Maar het is inderdaad goed om op deze manier te voorkomen dat bij klasse extensies perongeluk het select object naar buiten komt.

[HuHu]

Hmm... ik kijk er nu nog eens naar, maar die getDbSelect() zelf is public. Dus iedereen kan sowieso al bij de $dbSelect komen.

Dus ik denk eigenlijk dat de clone is bedoelt om interne wijzigingen aan het dbSelect object niet naar buiten te laten komen, in plaats van dat ze het dbSelect object zelf proberen te beschermen.

[nika]

Hmmm, of als security measure. Om te voorkomen dat er ongewenste WHERE clauses o.i.d. van vorige queries achterblijven in hetzelfde dbSelect object, die mogelijk kunnen leiden tot een false positive authentication.

Bedankt in iedergeval voor de korte discussie.

Nika_Auth_Adapter_DbTableSalted werkt inmiddels

[HuHu]

Ik weet niet precies wat je hebt gemaakt natuurlijk, maar weet je ook dat je aan de Zend_Auth_Adapter_DbTable een credentialTreatment kunt toevoegen? Volgens mij kun je dan ook zoiets maken:

PHP:

$auth->setCredentialTreatment('MD5(?'. $salt . ')');

Dat doet misschien ook al wat je wilt.

[nika]

Jouw methode werkt natuurlijk prima als je:

- een site-wide salt gebruikt, hetgeen vanuit securiy perspectief wordt afgeraden
- "slechts" MD5 hashes gebruikt

*In de paranoia modus gaat*

Ik wilde per user salts. Daarnaast worden de salts bij ieder inlog opnieuw bepaald en worden dus bijbehorende passwords opnieuw gesalt en gehashed.

Bovendien zijn bij gangbare versies van MySQL (5.0; 5.1) SHA2 hashes niet supported, dus moest ik in code hashen.

Ik check of de identity aanwezig is, haal dan bij identity horende salt op, salt en hash de credential en geef het geheel dan door aan de inherited _authenticate() functie vna Zend_Auth_DbTable

[Cartman!]

nika schreef op donderdag 02 september 2010 @ 14:17:
Daarnaast worden de salts bij ieder inlog opnieuw bepaald en worden dus bijbehorende passwords opnieuw gesalt en gehashed.

Uh...dus je slaat dan alsnog de wachtwoorden op zonder salt, of zelfs plain. Wat is dan het nut van je systeem?

[HuHu]

Cartman! schreef op donderdag 02 september 2010 @ 14:29:
[...]

Uh...dus je slaat dan alsnog de wachtwoorden op zonder salt, of zelfs plain. Wat is dan het nut van je systeem?

Bij het inloggen geeft de gebruiker zijn wachtwoord natuurlijk in plain-text op, dus je kunt die invoer opnieuw salten en opslaan.

[nika]

HuHu schreef op donderdag 02 september 2010 @ 14:31:
[...]

Bij het inloggen geeft de gebruiker zijn wachtwoord natuurlijk in plain-text op, dus je kunt die invoer opnieuw salten en opslaan.

Precies. En aangezien je weet dat het wachtwoord klopt na succesvolle authenticatie kan je dat password dus gewoon gebruiken.

iets als

code:

$hashedPassword = SHA256($salt . $this->_credential)

ga dat maar eens bruteforcen met rainbow tables o.i.d.

[ Voor 10% gewijzigd door nika op 02-09-2010 14:51 ]

[Freeaqingme]

Hoe genereer je je salt dan?

[Cartman!]

Ik ging er even vanuit dat je login gebruik maakte van salts danwel challenge/response, excuus. Ik hoop wel dat je HTTPS gebruikt ieder geval dan, je bent dan leuk bezig je database te beveiligen maar de verbinding is vrij om te kapen.

[nika]

freakingme schreef op donderdag 02 september 2010 @ 14:51:
Hoe genereer je je salt dan?

Dat is nog even een goed punt inderdaad. Wat is een echt random salt. Doe nu iets als

code:

$salt = hash('sha256', uniqid(mt_rand(), true) . microtime());

Cartman! schreef op donderdag 02 september 2010 @ 14:52:
Ik ging er even vanuit dat je login gebruik maakte van salts danwel challenge/response, excuus. Ik hoop wel dat je HTTPS gebruikt ieder geval dan, je bent dan leuk bezig je database te beveiligen maar de verbinding is vrij om te kapen.

ssl is natuurlijk een vereiste voor het versturen van het wachtwoord. Ik kijk ook nog even naar die http digest methode, maar dat lijkt niet echt lekker 100% ondersteunt en is natuurlijk lang niet zo veilig als een ssl.

[ Voor 47% gewijzigd door nika op 02-09-2010 14:55 ]

[Freeaqingme]

Je kan iets als dit doen: $salt = pack("d", rand().rand().rand().rand().rand());

Edit: deze read-up kwam ik een paar dagen geleden tegen, wellicht worth reading.

[ Voor 56% gewijzigd door Freeaqingme op 02-09-2010 15:09 ]

[nika]

Hmm hmm, er zijn natuurlijk veel methodes om een salt te genereren.

Wat is nu vanuit oogpunt van uniciteit de beste oplossing? Eigenlijk moet ik mn salt misschien niet hashen. Ongetwijfeld is ook SHA256 gevoelig voor collisions en zouden twee verschillende getallen potentieel dezelfde hash kunnen leveren.

Met het gevaar off topic te gaan: wat is volgens jullie de beste manier om een random salt te genereren?

[ Voor 3% gewijzigd door nika op 02-09-2010 15:10 ]

[Freeaqingme]

Wat ik hierboven paste met pack('d', $iets); met pack bestaat ieder karakter uit een ascii code van 0 tot 255. Met random integers alleen 48 - 57, met letters alleen 97-122 en met zowel upper als lowercase dingen nog eens 26 extra. Als je in een salt alleen letters & digits gebruikt kan dat met een rainbow table relatief makkelijk gematched worden (hoewel 't password wel langer is met salt dan wanneer je helemaal geen salt zou gebruiken). Tot zover ik weet zijn er nog geen rainbow tailbes die binary values gebruiken.

[nika]

Ga er vanavond eens mee bezig. Bedankt voor de tip. De read-up ziet er goed uit, zal er vanavond ook eens beter naar kijken.