Re: una chiave di troppo

From: From: Silvano Esposito
... potrei prevedere anche una cifratura della chiave utilizzata per la
>criptazione/decriptazione dell'informazione finale, ma il problema non si
>elimina.

From: Koba:
Una soluzione tipica e' usare la chiave di accesso dell'utente



Ciao,
non son sicuro di avere capito cosa vuoi fare ma propongo la mia soluzione.
Un sistema bifido.

Supponi una tabella contenente nome cognome e cellulare.
Aggiungi due campi
campo:  hash_password (password di login dell'utente criptata con md5) come nella soluzione di KOBA.
campo:  hash_admin  (campo BLOB (o TEXT) contenente un array serializzato (tipo serialize() del php)
 e criptato con password unica e conosciuta solo dal webmaster scritta su foglio)


In tal modo se l'utente perde la password invia una richiesta al webmaster
che deve intervenire e, attraverso uno script inserisce:

chiave segreta uguale per tutti i record +  IDRECORD + NUOVA PASSWORD

lo script decripta il campo hash_admin, aggiorna i dati dei singoli campi e l'hash_password


La notte un crojob di root aggiorna gli hash_admin con i nuovi hash dei campi che l'utente ha modificato (ad es. se ha modificato il proprio cellulare)


Ci sono due inconvenienti..
1. l'intervento del webmaster che azzera la password dell'utente che l'ha dimenticata
(ma anche questo potrebbe essere risolto da un cronjob notturno o orario; in tal caso l'utente aspetta il giorno dopo o l'ora dopo)
2. c'è un lasso di tempo in cui i dati dell'utente non sono sincronizzati con la versione
serializzata nell'hash_admin. (riducibile a 5 minuti con un ulteriore cronjob che aggiorna i campi modificati)



Si lo so è una soluzione da fabbro.
ciao.


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List