[Mysql] Chiave primaria in MD5?

[drAlberT]

Originariamente inviato da piero.mac
Essendo l'id univoco, lo sara' sicuramente anche il valore ottenuto con MD5()

IMHO non è corretto.

nessuno ti assicura che md5() faccia corrispondere a due num diversi due hash diversi, almeno in linea di principio.

è ovvio che, per un dato valore MD5, esistono infinite stringhe di lunghezza arbitraria che producono lo stesso hash.... non è detto che questo valga anche per numeri +/- contigui..

intendo dire che forse per 2^32 combinazioni ( i numeri usati come id) contigue l'md5() *potrebbe* pure non collidere ... ma IMVHO questo non è assicurato e,sebbene con bassa probabilità, potrebbe accadere

[piero.mac]

Originariamente inviato da Threepwood
anche questa è un'ottima idea come faccio però per settarglielo in automatico alla scrittura della riga? (intendo... cosa metto come default value? )

puoi farlo con due query, un insert seguito da un update, oppure estraendo l'ultimo id inserito (mysql_insert_id() + 1)...

INSERT lasciando vuoto sia id che id_md5
UPDATE tabella set id_md5 = MD5(last_insert_id(id))

L'update deve seguire immediatamente l'insert....

[Threepwood]

ragionando x assurdo si ma visto che la probabilità e bassissima mi accontento

[drAlberT]

mah .. de gustibus

BTW, volendo comunque seguire la strada della insert+update ricordati di lockare la table prima

[Threepwood]

Originariamente inviato da piero.mac
puoi farlo con due query, un insert seguito da un update, oppure estraendo l'ultimo id inserito (mysql_insert_id() + 1)...

INSERT lasciando vuoto sia id che id_md5
UPDATE tabella set id_md5 = MD5(last_insert_id(id))

L'update deve seguire immediatamente l'insert....

che ne dici, altrimenti, di un

INSERT INTO TAB (NOME,IDMD5) VALUES('PIPPO',md5(rand()))

[piero.mac]

Originariamente inviato da drAlberT
IMHO non è corretto.

nessuno ti assicura che md5() faccia corrispondere a due num diversi due hash diversi, almeno in linea di principio.

è ovvio che, per un dato valore MD5, esistono infinite stringhe di lunghezza arbitraria che producono lo stesso hash.... non è detto che questo valga anche per numeri +/- contigui..

intendo dire che forse per 2^32 combinazioni ( i numeri usati come id) contigue l'md5() *potrebbe* pure non collidere ... ma IMVHO questo non è assicurato e,sebbene con bassa probabilità, potrebbe accadere

Vai tranquillo..... non accade.... specie con i numeri. Se proprio dubiti basta settare UNIQUE la colonna con l'HASH.... ma e' un trattato sul sesso degli angeli.... Anche la possibilita' di fare 6 al superenalotto esiste, ma e' milioni di volte piu' semplice fare un cinque. Al massimo mi e' uscito un quattro.

Se dovesse custodire i conti correnti del cittadino d'italia (ILLO) magari qualcosa in piu' che passare i dati da querystring ci vorrebbe. Una semplice sessione per esempio non e' certo modificabile da un utente biricchino....

[piero.mac]

Originariamente inviato da Threepwood
che ne dici, altrimenti, di un

INSERT INTO TAB (NOME,IDMD5) VALUES('PIPPO',md5(rand()))

Ma fai come vuoi..... chissa' se arrivera' mai per me il giorno di trovare due hash di md5() uguali.... ho perso la speranza ...

Come ho detto su una semplice sessione toglie il medico di torno. poi puoi anche bluffare facendo passare un hash a 140 byte e non solo a 128 come e' md5().... che serva assolutamente a nulla... tanto per far sfogare il monello di turno. L'id vero lo passi via POST o via session.... dov'e' il problema????

[daniele_dll]

Originariamente inviato da drAlberT
anche in questo caso però stai supponendo che tale char32 sia univoco, cosa che in realtà dovresti controllare a mano rallentando di molto la cosa...
è vero che la probabilità di collisione è bassa .. ma cresce col crescere del sito... un campo int in + al db non crea di certo problemi, ne crea di + la sua assenza IMHO

si, è vero, ma in realtà le reali possibilità sono praticamente zero

tieni conto che una tabella di sessioni può raggiungere cifre alte, ma nell'ordine di qualche migliaio di righe e anche in questo caso (se la gb viene eseguita ad ogni login e la durata della sessione è di 30 minuti avresti un bel po di utenti connessi) le reale possibilità che ti capiti una chiave uguale sono comunque molto ridotte, anche perché, se usi un MD5 per salvare la sessione, se ne esce uno uguale, è moltoooo peggio, immagina 2 md5 che escono...e il primo è quello di un utente loggato...succederebbe che (ovviamente poi molto dipende dal codice)

- utente uno entra
- utente uno fa login
- entra utente due
- utente due ha lo stesso hash della sessione uguale a quello dell'utente uno

essendo che mysql restituisce in ordine di inserimento le righe se non viene specificato alcun ordinamento al momento di inserimento delle chiavi facendo una select in base all'hash ed un fetch si tirerebbe fuori la prima sessione e quindi il secondo utente verrebbe trattato come il primo

nel cookie allora dovrebbe starci un hash generato da un dato CERTAMENTE unico, e nel caso specifico delle sessioni, l'unico dato certamente unico è quello della chiave primaria, perché, per definizione ne può essere presente uno solo, ma se viene trovato il sistema a generarsi uno scanner non ci vuole nulla e scoppia tutto, e comunque la chiave primaria autoincrement (quindi un numero) non può essere messo dentro un cookie xche sarebbe ancora più semplice.

sono andato a ritroso, nel senso che sono partito dai motivi per cui non usare una chiave autoincrement in una tabella delle sessioni, e basta, ovvero senza un dato casuale, per gestire le sessioni.

è vero che c'è la possibilità che capiti un doppione, ma preferisco questa (che evito con una select aggiuntiva al momento della creazione delle sessioni che non causa, praticamente, overhead) che lasciarmi una possibile entrata, possibile vuol dire che potrebbe anche essere difficilissima da trovare, ma comunque c'è una vaga possibilità.

alla fin fine...due md5 generati da un uniqid che a sua volta viene generato da un microtime sono sufficentemente "unici" nel senso che se ne ho mille, o 10 mila, le possibilità di beccare un doppione sono nulle, dato che usando md5 posso ottenere fino a 340,282,366,920,938,463,463,374,607,431,768,211,00 0 combinazioni (insomma, ci vuole proprio tanta sfiga per beccare il doppione ed avere problemi se non si fa un controllo)

il tuo discorso è perfettamente valido, ma se non si usa un dato "casuale" che per sua natura si può ripetere, le possibilità di bucare un sito salgono alle stelle

certo, poi molto spesso ci sono tanti altri crateri, ma quelli facili da tappare preferisco chiuderli ))

[drAlberT]

il mio discorso non era sulla necessità, sacrosanta, di tappare anche le + piccole falle... ma su quella che ritengo altrettanto sacrosanta di implementare un sistema che non sia fallace... e non che lo sia ma con una probabilità bassissima!

un bel cript(), con seme dato, o md5 se + vi piace, di un dato randomico e storato in un apposito campo cid e un controllo fatto sul cid danno IHMO la sicurezza necessaria mantenendo l'itegrità formale del db, che manterrebbe una sua chiave realmente univoca (come deve essere) data da un semplice ed economico auto_increment...

il mio discorso insomma non è nel non fare l'md5.. ma nel non usarlo come chiave primaria! tutto qui

[daniele_dll]

Originariamente inviato da drAlberT
il mio discorso non era sulla necessità, sacrosanta, di tappare anche le + piccole falle... ma su quella che ritengo altrettanto sacrosanta di implementare un sistema che non sia fallace... e non che lo sia ma con una probabilità bassissima!

un bel cript(), con seme dato, o md5 se + vi piace, di un dato randomico e storato in un apposito campo cid e un controllo fatto sul cid danno IHMO la sicurezza necessaria mantenendo l'itegrità formale del db, che manterrebbe una sua chiave realmente univoca (come deve essere) data da un semplice ed economico auto_increment...

il mio discorso insomma non è nel non fare l'md5.. ma nel non usarlo come chiave primaria! tutto qui

è vero, ma alla fin fine si risolve tutto con una stupidissima select che verifica se è presente l'md5 o meno