Newsgroup: it.comp.os.linux.sys
Titolo: Sistema di autenticazione centralizzato

In poche parole, dovrei ingenierizzare un sistema di login centralizzato 
  e certificare la validità degli utenti.
Spiego meglio:
Immaginate un sito (https ovvioamente) in cui un utente con conoscenze 
pari a zero deve semplicemente compilare un form con i propri dati 
anagrafici + numero di cellulare, codice fiscale ed e-mail, terminato il 
sistema stampa un contratto in .pdf precompilato con i suoi dati e 
relativo username e password, l'utente a questo punto ha 3 opzioni..
1) se è in possesso di firma digitale firma il contratto e fa l'upload 
del file sul server
2) se non è in possesso di firma digitale stampa il contratto, lo firma, 
  lo scansiona con uno scanner aggiungendo una scansione della carta 
d'identità ed esegue l'upload.
3) se non possiede uno scanner invia a mezzo fax o posta ordinaria 
contratto e copia della carta d'identità
A questo punto un operatore avendo riconosciuto l'utente lo abilita, 
l'utente riceve via mail l'invito a modificare la password generata 
randomicamente dal sistema con una nuova che verrà salvata nel DB 
criptata MD5 SHA1
Ora, fatto ciò l'unica persona al mondo a conoscere la password dovrebbe 
(meglio usare il condizionale, poi vedremo il perché) essere l'utente 
che ha fatto la richiesta.
L'idea quindi è avere un web service in grado di autenticare un utente 
(Nome, Cognome n° codice fiscale) indipendente dalle proprie 
applicazioni in maniera da poter realizzare servizi evoluti ad esempio 
un sistema di votazione on line che impedisca de facto un doppio voto o 
simili.
Ora, premesso che si tratterebbe di un cluster di DB Mysql in modalità 
master->slave ed un cluster di apache che interrogano i DB slave privi 
dei privilegi di scrittura e quindi praticamente blindati (adottanto 
tutte le precauzioni del caso ovviamente).
Come impedire ad esempio che un utente sprovveduto utilizzi un PC già 
infetto da un key-logger sia in fase di registrazione che successivamente?

 infetto da un key-logger sia in fase di registrazione che successivamente?
<ironia>
Spari all'utente o non gli dai alcun accesso
</ironia>
Battute a parte, tu puoi gestire la sicurezza dalla connessione del
browser al webserver in poi verso il db. Se l'utente ha un pc infetto tu
non ne sai né puoi saperne nulla.
Se l'utente ha una telecamera alle sue spalle, non puoi saperne nulla.
Se l'utente si scrive la password in chiaro e la attacca con lo scotch
sul pc (ho visto anche questo), tu non ci puoi fare nulla.
Se l'utente pubblica la sua password, idem.
Questo è il classico PBTKATC (Problem Between The Keyboard And The
Chair, mo' l'acronimo non sarà esattamente questo, ma il senso è chiaro).
Alcune banche, per tamponare ciò, utilizzano un sistema con una matrice
di codici e ogni volta che fai una operazione ti chiedono i numeri, le
lettere o i simboli che si trovano nelle posizioni indicate, posizioni
che variano *casualmente* ad ogni richiesta. (una richiesta possono
essere A2 e F5, ad un'altra possono essere B6 e Q1, tanto più grande è
la matrice tante più combinazioni ci sono, e tutti hanno giocato almeno
una volta a battaglia navale)
Le tessere o i libretti che vengono consegnati per posta ordinaria sono
numerati e sono (o dovrebbero essere) diversi per ciascun utente.
Un po' come i vecchi metodi anticopia della LucasArts e altre software
house per i videogiochi negli anni '90 quando si andava solo con i floppy.
PSK