
Originariamente inviata da
MItaly
Mm al di là del codice specifico, se ho ben capito la tua idea sarebbe non associare esplicitamente l'hash di salt+password all'utente, ma tenerli "alla rinfusa" in un'unica tabella, e usare il salt per evitare collisioni (oltre agli usuali problemi di sicurezza che risolve il salt).
Il miglioramento di sicurezza dovrebbe derivare dal fatto che, mancando l'associazione utente-password, dovrebbe essere più complesso cercare di craccare una password di un utente specifico, dato che non sai qual è l'hash corrispondente, ed è inoltre possibile aggiungere degli hash aggiuntivi "per depistaggio" alla tabella.
Mi confermi che ho compreso la cosa correttamente?
Si hai riassunto il punto

Originariamente inviata da
Scara95
Qualsiasi password restituisca uno degli hash presenti nella tua tabella hashes viene accettata, quindi invece di rendere il tutto più sicuro l'hai reso meno sicuro perché ci sono più possibilità fra cui scegliere
Non credo, hai letto il mio codice?
Contando che viene generate anche un salt (che possiamo, perchè no, rendere univoco), in questo caso non esisterà mai una combinazione salt+password che dia il risultato di un'altra chiave UNIVOCA della hash.
codice:
UNIQUE KEY(hash)
)ENGINE=innoDB;
// ...
# Inserisce una hash univoca, utilizziamo il loop per rigenerarlo nel caso
# sia già presente nella tabella.
#
# L hash è generato dalla password dell utente concatenato al salt:
# SHA2(CONCAT(salt, password), 512)
hashGen: LOOP
SET @rndSalt = GEN_RND_STR();
SET @hash = SHA2(CONCAT(@rndSalt, _password), 512);
SET @SQL = '
SELECT @t := COUNT(*)
FROM hashes
WHERE ? = hash';
PREPARE stmt FROM @SQL;
EXECUTE stmt USING @hash;
DEALLOCATE PREPARE stmt;
IF ((SELECT @t) = 0) THEN
LEAVE hashGen;
END IF;
END LOOP hashGen;
Sei sicuro di ciò che stai dicendo? Puoi affermarlo con un esempio pratico?
Sono curioso di una tua continuazione...