Va bene usare le firme digitali come meccanismo per le email di verifica dell'account?

Question

Va bene usare le firme digitali come meccanismo per le email di verifica dell'account?

#1 da (0 voti)

1

Sto implementando la verifica dell'account (i registri degli utenti, i messaggi e-mail, il link seguente per verificare l'indirizzo e-mail).

Molte esercitazioni che vedo implicano l'inserimento di una colonna nella tabella utenti per una stringa casuale, che viene generata prima dell'invio dell'e-mail di verifica e inclusa nella stringa di query del link di verifica.

Sto pensando di usare una chiave pubblica per crittografare l'indirizzo e-mail e collegare invece il risultato alla stringa di query. Quindi, dopo aver ricevuto una richiesta di verifica, decrittografare il parametro della stringa di query con la chiave privata e confrontarlo con l'indirizzo email. In questo modo, non c'è bisogno di una colonna aggiuntiva

Tuttavia sono davvero traballante nella mia conoscenza della sicurezza delle informazioni. E 'questa una buona idea? Funzionerebbe? Dovrei cancellare l'indirizzo prima di crittarlo con la chiave pubblica?

email digital-signature asymmetric

posta Sava B. 04.08.2016 - 06:30

fonte

1 risposta

Leggi altre domande sui tag email digital-signature asymmetric

Protezione della privacy su Internet in casa a livello di router [chiuso] Come creare avvisi per il firewall Watchguard in SIEM

score 0 · Accepted Answer

Stai citando la crittografia dell'email e la firma digitale. Si tratta di due cose diverse che, sebbene possano essere utilizzate entrambe nel tuo caso, hanno risultati pratici diversi: utilizzando la crittografia, stai nascondendo i dati crittografati dalla vista (l'indirizzo email).

Detto questo, in teoria, il tuo schema dovrebbe funzionare bene. In pratica, tuttavia, vorrei evitare questo schema:

La maggior parte degli algoritmi di crittografia a chiave pubblica (o firma digitale) genera grandi risultati: troppo grandi per adattarsi comodamente a una stringa di query. O meglio, potrebbe rientrare nella dimensione massima consentita da la maggior parte dei browser , ma probabilmente non in un'unica riga di posta elettronica che sarà un inconveniente per i tuoi utenti.
Il tuo schema crea un singolo punto di vulnerabilità: una volta compromessa la chiave privata, tutte le transazioni future sono contaminate. Se si utilizza invece l'approccio regolare "chiave casuale in una tabella DB", non si dispone di questo singolo punto di errore: un utente malintenzionato dovrebbe compromettere il DB esistente per rompere il sistema.
Il tuo schema scambia un po 'di spazio su DB per una notevole complessità nel codice, aumenta la superficie di attacco e, potenzialmente, ti rende vulnerabile a un DOS (poiché la convalida della chiave pubblica non è esattamente così economica in CPU e memoria come ricerca DB).

Quindi, a meno che non ci sia un vero e proprio business case (ad esempio, se c'è un strong bisogno di essere in grado di validare una query senza raggiungere il database), suggerisco di usare l'approccio più comune.

Vorrei aggiungere: in generale, mi piace attenermi al principio KISS con il mio software. Dato due modi per ottenere lo stesso risultato, cerco di attenermi a quello che richiede meno codice.