Concetto stringa di identificazione

[CodiceProg]

A livello di concetto,avendo
una tabella di con gli username e una con i prodotti acquistati
Mandando una mail di conferma di acquisto si associa una stringa casuale per controllare che tutto sia validoSi deve associare a username o a prodotti?
Grazie in anticipo

[longilineo]

parti dal presupposto che ti servirebbe qualcosa di univoco e le funzioni hashing più note e utilizzate non lo sono, per quanto buone possano essere ci sono delle collisioni. Detto questo puoi risolvere semplicemente prendendo ciò che rende univoco un' acquisto, io penso che tu abbia un db con almeno le seguenti tabelle con almeno i seguenti campi:

Prodotti
id, descrizione,prezzo

Utenti
id, username, password

Acquisti
id, utente_id, data, seme, scadenza, stato

Dettaglio
id, acquisti_id, utenti_id, prodotti_id

Già l'id dell'acquisto è univoco e permette perfettamente di inquadrare una vendita(utenti e prodotti annessi), quindi potresti usare come ultima/e cifra/e del codice univoco il valore di tale campo e a questo prependi l'hashing tramite sha1 su qualcosa che ritieni sicuro e segreto tu, poi ricorda che di sicuro non c'è niente per sempre, quindi sicuramente visto che l'ordine va confermato entro una certa data fa si che il codice sia valido fino a quella data.

Quindi ricapitolando e considerando anche le temporaneità della validità del codice di conferma potresti fare:

-Acquisto.id = 5
-Scadenza validità conferma: 21-12-2011
-seme valido solo per l'acquisto 5 e solo fino alla scadenza: "fkld5fd34xvklsflk?!ù"

Quindo il codice di conferma sarà qualcosa del tipo
sha1("21-12-2011"."fkld5fd34xvklsflk?!ù").5

Ti spiego il perchè si mette alla fine l'id dell'acquisto... sha1 ha output a lunghezza fissa mentre l'id essendo autoincrementato no, quindi per prendere l'acquisto prendi solo le ultime cifre. sha1 dovrebbe generare a prescindere dall'input una stringa di 40 caratteri quindi tutto ciò che viene dopo è l'id dell'acquisto. Per essere sicuro, che il codice sia valido confronti i primi 40 caratteri del codice con sha1("21-12-2011"."fkld5fd34xvklsflk?!ù"). Se matchano e "21-12-2011" è minore della data odierna allora ti è arrivata una conferma valida.

[eiyen]

Aggiungo alla chiarissima spiegazione un'osservazione tecnica per amor di discussione (è una divagazione tecnica OT rispetto all'argomento principale) su una questione tecnicamente molto interessante: la probabilità delle "collisioni" c'è, ma è bassissima e solitamente non incide sulla sicurezza (moltissimi sistemi registrano le password usando codifiche hash e basta): volendo creare una codifica univoca si può benissimo usare hash+id_unico, ma se si vuole incrementare di un ordine (tradotto non dal gergo: sensibilmente) la sicurezza questo risultato andrebbe criptato.

Supponiamo che un attacco voglia "forzare" un codice legato all'account "esempio@example.com":
- se il sistema si basa su una codifica hash in funzione dell'account la sicurezza è legata alla codifica hash stessa
- se aggiungiamo un id univoco l'ordine di grandezza è analaogo al precedente: basta "attaccare" il sistema ciclando sugli id (*: la sicurezza è maggiore, ma non sensibilmente, ossia tale da giustificare - in generale, poi ci sono i casi specifici - una procedura dedicata)


Criptando la chiave hash+id otteniamo invece un'ottima soluzione che incrementa effettivamente il grado di sicurezza.



(*) attenzione: "ordine di grandezza" nella sicurezza significa che se ci vuole T1 tempo per forza il primo sistema e N*T1=T2 per il secondo, l'ordine è lo stesso (un fattore lineare). Inoltre per conoscere l'id è sufficiente fare un'ordine vero oggi e domani (ottenendo i valori n1 ed n2) e possiamo limitare N a pochi valori (avendo idea di quanti ordini si fanno in un giorno e degli ultimi valori raggiunti).

[CodiceProg]

intanto grazie,gentilissimi ,ed eventualmente una tabella a parte che collega id utente a id prodotto?

[longilineo]

la tabella dettaglio lo fa anche se in realtà il campo 'utenti_id' è superfluo. La struttura di dettaglio potrebbe essere semplicemente

Dettaglio
id, acquisti_id, prodotti_id

Alla fine non è il prodotto ad essere legato ad un utente, ma l'acquisto e, indirettamente, tutti prodotti che questo comprende.

Gli acquisti con la struttura tabellare indicata nel mio primo post sono già collegati agli utenti.