Se l'input per la domanda di sicurezza è completamente digitale, la risposta a una domanda di sicurezza dovrebbe essere sottoposta a hash (o almeno crittografata) sul server di autenticazione?
Presumo che il modello a cui stai cercando di difendersi sia il luogo in cui un utente malintenzionato ha accesso al database. Se è così, sì, è una cattiva idea se un utente malintenzionato può compromettere un account solo conoscendo quei dettagli.
Il mio consiglio sarebbe quello di convertire la risposta in maiuscolo, quindi sale + hash. Se lo desideri, puoi anche ridurlo o comprimere tutti gli spazi bianchi. Ciò fornisce una misura di sicurezza ragionevole senza ridurre l'usabilità.
Se quelle domande forniscono lo stesso livello di accesso della password, allora per tutti gli scopi pratici sono una password e dovrebbero essere trattate come una. Applica lo stesso livello di protezione a tutte le password memorizzate.
La risposta è sì, dovresti sempre cancellarlo .
Perché abbiamo hash cose come password? Due ragioni: principalmente perché le persone usano spesso la stessa password per molte cose diverse, e in aggiunta (è più un fortunato effetto collaterale) per impedire agli attaccanti di accedere quando hanno ottenuto l'accesso al database di sola lettura.
Quindi non pensi che il primo nome dell'animale domestico o della madre di un utente sia anche un dato che userebbe su più servizi? O che potrebbe potenzialmente essere usato per attacchi di social engineering? O potrebbe essere usato per resettare la password e anche ottenere l'accesso?
Per questo motivo, dovresti proteggere le risposte alle domande di sicurezza contro gli attaccanti (e gli amministratori!) allo stesso modo delle domande con le password.
Perché non crittografarlo?
La crittografia è reversibile, consente di accedere ai dati mentre non è necessario. Uno dei casi che stai cercando di impedire proteggendo i dati del database, è un caso in cui il server è compromesso o in cui un addetto ai lavori ha cattive intenzioni. In entrambi i casi, potrebbero utilizzare la chiave di decrittografia per invertire la protezione. Con discreto hashing , questo non è più possibile.
Ma per quanto riguarda la punteggiatura? Non puoi abbinare un hash a meno che non sia esatto.
Le persone potrebbero usare più parole in una risposta, e una volta potrebbero usare le maiuscole, altre volte potrebbero rimuovere spazi tra le parole o mettere un punto dietro la frase ... quindi suggerirei di normalizzarlo per rimuovere almeno gli spazi , rimuovi la punteggiatura e le lettere maiuscole minuscole.
Se hai salvato testo in chiaro o crittografato, devi comunque scrivere un algoritmo di confronto. Questo algoritmo dovrà anche ridurlo a una versione di base per poter decidere se si tratta di una corrispondenza. Qualunque cosa tu voglia fare quando scrivi quell'algoritmo di comparazione (quindi cose come il minuscolo), dovresti applicare prima dell'hash per ottenere lo stesso effetto.
Come menzionato da @Polynomial e @ B-Con , la memorizzazione delle domande di sicurezza non crittografate è pericolosa se queste possono essere effettivamente utilizzate come password. Ma anche se così non fosse, non dovresti memorizzare le risposte di sicurezza non crittografate.
Le domande di sicurezza comuni richiedono dettagli personali, come "Qual è il nome di tua madre?" (presupponendo un sistema in cui non è possibile inserire domande personalizzate o dove l'utente sceglie solo una delle domande esistenti). Non sei l'unico server che può richiedere tali dettagli, le stesse informazioni possono essere utilizzate per compromettere le informazioni su altri sistemi che hanno le stesse domande e risposte sulla sicurezza.
Anche se esiste una risposta accettata e un consenso sul fatto che dovrebbe essere sottoposto a hash, vale la pena notare che ci sono casi in cui ciò potrebbe non essere desiderabile.
Il più ovvio è dove ti vengono chiesti i caratteri selezionati dalla risposta. Questo fornisce protezione contro gli attacchi di replay. Ma non è possibile verificare la risposta rispetto ai dati hash senza archiviare tutte le possibili combinazioni di hash e, di conseguenza, si rende molto, molto più facile da forzare il testo chiaro (cioè si perde il beneficio di hashing). In genere questo approccio viene utilizzato insieme a una password (con hash) per l'autenticazione.
Un ulteriore caso in cui questo potrebbe essere applicabile è dove potresti voler fornire un po 'di serenità nella convalida, ad esempio permettendo variazioni in lettere maiuscole. Un caso d'uso per questo sarebbe per un token che viene usato di rado, ad es. in una reimpostazione della password, ma deve essere applicata con cautela e in combinazione con altri controlli (ad esempio, l'invio di un token di ripristino all'indirizzo e-mail registrato anziché consentire una modifica immediata della password).
Si tratta di compromessi sulla sicurezza. Ma la sicurezza perfetta è costosa e ostacola la cosa che gli utenti vogliono fare.
Il modo più sicuro in cui la password può solo essere resettata se la risposta segreta è nota procedi come segue:
x={hash(password)}priv_S
dove priv_S è la risposta segreta (chiave privata) e la chiave pubblica (pk_S) è memorizzata.
E per verificare fai:
I=user's typed secret answer
x=={{x}pk_S}priv_I
Per accedere:
$username=<username>&&$hash=={x}pk_S
Ciò consente di modificare la password solo se la risposta segreta è nota, ma consente di accedere senza di essa.
Leggi altre domande sui tag passwords secret-questions