Come posso rafforzare quelle domande di sicurezza le risposte non dovrebbero essere le stesse e come crittografare?

Se stai realizzando un'applicazione web standard, TLS è il tuo unico metodo "sicuro" per proteggere gli utenti dagli attacchi MitM e dallo sniffing del traffico. Dai un'occhiata alla mappa di ipviking degli attacchi informatici in tempo reale; un gran numero viene dalla Cina perché la crittografia è in gran parte fuorilegge e le richieste dei browser possono essere dirottate. (La maggior parte dei ragazzi di infosec che conosco sono d'accordo sul fatto che X.509 è rotto, l'IETF è compromesso, TLS è probabilmente indebolito intenzionalmente dalla NSA ( un po 'come questo ), e gli interi spazi chiave per le curve RSA e ellittiche sono precalcolati dai governi, tuttavia è ancora meglio del traffico non criptato.)

Se è necessario utilizzare le domande di sicurezza, suggerisco di mettere tutto in minuscolo, rimuovere gli spazi bianchi e l'hashing con un sale casuale memorizzato lungo il lato (potrebbe essere un singolo salt memorizzato come parte di un record utente). Suggerisco almeno hash a 256 bit e 100 round (meno se l'algoritmo hash è già lento). Gli hash di Bcrypt sono anche abbastanza buoni perché implicano la crittografia di un hash e la memorizzazione di salt come parte della stringa hash.

Se non usi bcrypt, assicurati di non usare un semplice str1==str2 booleano per controllare la risposta; dovresti usare qualcosa come la seguente, che eviterà l'attacco al canale laterale di confronto delle stringhe.

function compHashes ($h1, $h2) {
    $r = 0;
    if (strlen($h1) !== strlen($h2)) return false;
    for ($i=0; $i<strlen($h1); ++$i)
        $r |= ord($h1[$i])^ord($h2[$i]);
    return $r == 0;
}

Le considerazioni per le app binarie sono un po 'diverse in quanto è possibile codificare o raggruppare una chiave pubblica (o più) e utilizzare NaCl per generare chiavi private client e gestire strette di mano e crittografia tra server e client. Ci sono librerie in ogni linguaggio compilabile per questo, e scrivere un wrapper per una libreria collegata staticamente non è troppo difficile se questa è la rotta che scegli. Rolling your crypto è decisamente sconsigliato se non si ha molta familiarità con la crittografia e le questioni di infosec.

non puoi semplicemente confrontare le stringhe che l'utente inserisce?

Per evitare lo sniffing, è necessario crittografare le risposte sul client, passare la chiave pubblica del server al client e utilizzarlo per crittografarle prima di passarle di nuovo al server. In alternativa, usa solo le comunicazioni SSL.

Le domande di sicurezza sono inutili. Non aggiungono sicurezza ma infastidiscono gli utenti. Fai ciò che fanno le aziende serie e verifica l'identità tramite telefono cellulare o invia semplicemente un link per la reimpostazione della password all'e-mail associata (caso in questione: Stack Exchange).