Autenticazione sicura per l'utente Web anche dopo la compromissione del database lato server

5

Ormai, dovremmo sapere tutti usare bcrypt o scrypt per archiviare gli hash delle password salate con un numero sufficiente di round. (Vedi, ad esempio, link ) La lezione: supponiamo che il tuo database di autenticazione sarà compromesso ad un certo punto.

Dovremmo anche sapere come progettare i cookie di autenticazione utente che soddisfano il livello di sicurezza e riservatezza che la nostra applicazione richiede utilizzando HMAC con chiavi per utente. Il documento più citato che ho visto è link .

Tuttavia, ogni documento e proposta che ho letto che affronta l'autenticazione sicura dell'utente affronta una serie di problemi diversi e sovrapposti (ad esempio intercettazioni, manomissioni e attacchi di replay) e sono spesso finalizzati alla memorizzazione di opaco-to-the- anche i dati dell'utente.

Non riesco a trovare nessuno che indirizzi come rendere i cookie di autenticazione utente lato client resistenti agli attacchi anche dopo che il database di autenticazione del server è stato compromesso.

Il documento sopra, per esempio, si basa solo sulla segretezza della chiave del server. Molte implementazioni che ho visto generano anche un token per utente che viene utilizzato nell'HMAC e memorizzato sul server. In entrambi i casi, una volta compromesso il segreto del server, è banale falsificare le credenziali di qualsiasi utente.

Esistono riferimenti o implementazioni note che coprono questo scenario per le tipiche applicazioni Web (ad esempio, al di fuori degli ambienti aziendali e bancari)?

    
posta Michael 05.10.2012 - 19:50
fonte

1 risposta

2

Se l'intero server è compromesso, allora qualunque cosa il server può fare, anche l'aggressore può.

Pertanto, l'unico modo per avere un'autenticazione dell'utente che resiste a un compromesso totale del server è basare quell'autenticazione su qualcosa che l'utente può fare, ma che il server non può , ma tale che il il server può verificare che l'utente lo stia facendo. Ciò richiede una firma digitale . L'utente dovrebbe in qualche modo memorizzare una chiave privata da qualche parte sulla sua macchina, e usarlo per firmare una sorta di sfida inviata dal server.

La chiave privata non dovrebbe essere accessibile da Javascript; in caso contrario, l'autore dell'attacco potrebbe inserire codice JavaScript che recupera la chiave privata dell'utente. In un contesto Web, le firme digitali ma senza il codice inviato dal server, fanno riferimento ai certificati dell'utente

.

Questo può essere fatto. Inoltre, questo è fatto (l'ho visto usato da alcune banche, emettendo certificati ai loro clienti). SSL supporta i certificati lato client e le versioni recenti dei browser sono diventati quasi user-friendly quando si tratta di utilizzarli. Potresti persino distribuire smartcard (o gadget equivalenti che si collegano a una porta USB, per semplificare l'installazione).

    
risposta data 05.10.2012 - 20:05
fonte

Leggi altre domande sui tag