Newsgroup: it.comp.lang.delphi
Titolo: Memorizzare password criptata (Web Application - D2006)

Utilizzando il file Web.config è possibile memorizzare la password di un
utente criptata e con FormsAuthentication.Authenticate verificare tali
credenziali passando come parametri il nome utente e la password in formato
stringa.
Ma se si volesse usare un database access anzichè il Web.config (dato l'alto
numero di utenti)?
Ho allestito un form di test:
l'utente si registra al sito con una propria User e Passw e quest'ultima
viene criptata (sha1) dinamicamente (con HashPasswordForStoringInConfigFile)
e memorizzata nel db.
Successivamente simulo un login utente, scorro il db cercando la User quindi
cripto la password inserita dal visitatore e la confronto con quella
presente nel db.
Trattandosi di una stringa di caratteri l'operazione riesce.
La mia domanda è: a livello di protezione ha un senso?
Un'altro chiarimento al volo che forse richiederebbe un'altro post.
Esiste una sorta di EOF oppure
numerorecord := datatable1.rows.count;
for i := 0 to numerorecord - 1 do
begin
  // scorro i record
end;
è l'operazione corretta?
Grazie a chi vorrà / potrà rispondermi.
Valter

La mia domanda è: a livello di protezione ha un senso?
Che domanda è?
Che vuoi dire con "ha un senso" ?

 Che vuoi dire con "ha un senso" ?
si, non sono stato chiaro.
Intendo dire che inizialmente il mio test prevedeva la registrazione
dell'utente e relativo riconoscimento tutto in chiaro...poi ho pensato di
utilizzare l'hashing e come detto applico l'algoritmo nell'istante in cui
l'utente, compilato il form di iscrizione, conferma i dati.
Ma successivamente, al suo riconoscimento, non ho trovato il modo di
comparare la password di login, scritta in chiaro, con la medesima password
sul db, salvata in SHA1 ed ho pensato di applicare l'algoritmo anche al
momento del login confrontando così le due pass entrambe in hashing.
Mi chiedevo se l'operazione che effettuo è 'pulita' o se ci siano altri modi
più sicuri per effettuare la verifica...
Infatti mi trovo di fronte anche al problema di offrire all'utente il
classico 'recupero password'.
C'è un modo per riottenere la password dopo averla sottoposta all'algoritmo?
Ciao
V.

C'è un modo per riottenere la password dopo averla sottoposta all'algoritmo?
Dalla crittazione sì, dall'hashing no (è un digest, una firma che ha
sempre la stessa lunghezza).

 da darla indietro all'utente, su richiesta.
mmmh, però non mi viaggia in chiaro dal client al server al momento della
sua memorizzazione nel db?
Mi dirai, succede solo una volta poi tutte le successive validazioni saranno
protette...è questo che intendi o ho capito male?
Grazie per i tuoi utili chiarimenti
V.

sua memorizzazione nel db?
In quella sola occasione, la critti.

> In quella sola occasione, la critti.
ma D2006 offre anche questa possibilitą?
Nella FormsAuthentication ci sono solo le funzioni Encrypt e Decrypt che
possano richiamare l'attenzione ma non mi sembrerebbero idonee...tra l'altro
l'help su queste due voci mi ritorna "topic not available" e non le posso
verificare...
Devo forse importare qualche Reference particolare?
V.

> In quella sola occasione, la critti.
Dopo lunghe ricerche, a meno che non mi sia sfuggito qualcosa, mi pare di
aver capito che per la crittazione sono necessari algoritmi di terze parti
(o prodotti autonomamente) oltre che questo hashing non è poi così sicuro
(mi riferisco alle rainbow tables, database venduti o consultabili anche in
rete dove parrebbero memorizzate giga di stringhe con relativi hash).
Pazienza.
Una mia considerazione:
se davvero l'hashing ha queste debolezze (da quanto leggo le possibilità di
hackeraggio sfiorano la media del 90%) tanto vale rischiare con un algoritmo
in proprio...la stringa crittata sarà soggetta a reversibilità ma almeno non
sarà sufficiente una select WHERE HASH = ???).
Ciao
Valter

sarà sufficiente una select WHERE HASH = ???).
Continui a confondere hashing e crittazione.  Con un tuo algoritmo non
risolvi affatto il problema, perché sarà sicuramente meno efficiente e
sicuro di uno utilizzato a livello standard.  I problemi non si
superano reinventando la ruota.

Sě, le rainbow table esistono, [...]
p.s.: dalle rainbow table č possibile comunque difendersi (rendendole
inefficaci) prevedendo l'hashing di una password con un "salt", come
fanno i sistemi *nix.  Windows purtroppo non lo fa.
Questo tanto per ribadire che l'algoritmo di hashing *č* sicuro.

 superano reinventando la ruota.
Se un bel giorno Andrea Laforgia se ne uscisse fuori affermando di aver
generato un interessante algoritmo di crittazione non penserei che ha
reinventato la ruota...semplicemente che una nuova fatica si andrà ad
aggiungere al lavoro dei non pochi 'malintenzionati'.
D'altra parte perchè esistono decine di algoritmi? Forse perchè l'hacker
insegue e l'esperto di protezione fugge...è una costante.
Ciao
Valter

reinventato la ruota...
E invece dovresti pensarlo, perché sarebbe esattamente così.
Oltretutto, ti stai mettendo in una situazione impossibile, perché
Andrea Laforgia ti assicura che non gli verrà mai in mente di mettersi
a reinventare ciò che già c'è, sprecando del tempo.  Il fatto è che
tutti pensano di essere cervelloni, nel mondo della programmazione, e
invece la triste realtà è che pochissimi lo sono realmente.
Le possibilità che tu possa inventare qualcosa di più efficiente e
sicuro di ciò che già esiste sono ridottissime, ma se si convinto di
te stesso provaci, non voglio essere proprio io a scoraggiare un
novello Einstein.