La seguente serie di passaggi, abbastanza sicura, durante la registrazione e l'accesso sulla mia webapp? [chiuso]

0

Registra:

  1. Vengono confrontate entrambe le caselle di testo della password immessa dall'utente, se corrispondono:
  2. Aggiungi l'e-mail dell'utente alla tabella [users] nel database, per avere un ID utente per registrare in seguito tutto contro.
  3. Crea sale. Tutto abbastanza casuale e abbastanza complesso sarà sufficiente. UserName + date dateTime - MD5 hash. GUID, UserName + numero casuale hash, ecc.
  4. Registra il sale in una tabella Salt nel DB accanto all'ID utente e al nome.
  5. Aggiungi insieme la password dell'utente e sale.
  6. Hash that using Encryption1
  7. Hash that using Encryption2
  8. Registra ciò, insieme all'ID utente e ai relativi dettagli (se presenti) forniti nel modulo di registrazione.
  9. È stata inviata una verifica email opzionale, per accertarsi che stia utilizzando un indirizzo email legittimo.

Login.

  1. Ottieni il sale usando il nome utente inserito dall'utente
  2. Se viene restituito il sale, eseguire i passaggi 5-7 dal registro (pwd + salt, hash, hash)
  3. Quando abbiamo recuperato il sale, abbiamo anche ottenuto un ID utente, confrontare il risultato del passaggio 2 e l'ID con i record nel database.
  4. Se c'è una corrispondenza, l'utente ha utilizzato la propria email e password e può accedere.
  5. Crea una variabile di sessione e consenti loro di procedere.

Un vantaggio che credo che tutto ciò porti con sé, anche se l'accesso al mio intero database avviene in forma non protetta, la password è una stringa lunga 50 caratteri con hash due volte utilizzando diversi metodi di crittografia.

    
posta Иво Недев 01.11.2017 - 10:14
fonte

2 risposte

2

Seguendo il tuo esempio, inserirò i miei pensieri:

  1. Assicurati che l'indirizzo email non sia già in uso
  2. Per essere chiari, l'algoritmo di hash MD5 non aggiunge casualità a nulla. Di conseguenza, qui non sta facendo molto per te, se non rendendolo non immediatamente ovvio da dove proviene il tuo sale. Penso che sarebbe meglio usare un CSPRNG per generare il tuo sale piuttosto che basarlo sui dati dell'utente ed eseguirlo attraverso MD5 .
  3. Questa è un'applicazione nitpick, ma suona come se si stesse creando il record utente (passaggio 2) e poi si torna indietro e si memorizza il salt (passaggio 4) e quindi si memorizza la password hash (passaggio 8). Non c'è motivo per cui non puoi fare tutto questo in un'unica operazione di inserimento. Otterrai prestazioni migliori, ma soprattutto, il tuo codice sarà più semplice e facile da mantenere.
  4. Per essere chiari, non vuoi utilizzare un metodo di crittografia per cancellare le tue password. Hashing e crittografia sono due concetti separati con diversi algoritmi preferiti. Assicurati di fare l'hashing: non crittografare. Da quello che hai scritto, penso che tu sia sulla pagina giusta e stia semplicemente usando la terminologia sbagliata. È un errore facile da fare, ma la differenza è abbastanza critica che vale la pena segnalarlo.
  5. Non c'è una buona ragione per utilizzare due algoritmi di crittografia separati. L'unica ragione per fare una cosa del genere è far sì che le persone non possano provare a forzare le password se trovano il tuo database. Tuttavia, è una misura di sicurezza che si basa sul fatto che il codice sorgente viene tenuto segreto. A volte vengono entrambi trapelati. Questo passaggio non è inutile , ma non è altrettanto utile come potresti pensare e complica il tuo codice. Se si desidera una protezione come questa, includerei solo un pepe e attenersi a una singola passata di hashing della password sicura algoritmo.
  6. Al momento dell'accesso, assicurati di restituire sempre all'utente un singolo messaggio di errore non descrittivo "Combinazione nome utente / password non valida"
  7. Non fare un semplice confronto tra la password con hash dell'utente e quella che esce dal database (cioè $hashed_input == $user_hash ). Ci sono alcuni modi sottili in cui un simile confronto diretto può essere usato da un malintenzionato per aiutare a decifrare le password. Alcune lingue hanno metodi di supporto per facilitare il confronto delle hash delle password. Usane uno o trovane uno.

Ci possono essere un gran numero di modi sottili per i bug di sicurezza di insinuarsi nel sistema di login di un'applicazione, che può facilmente essere perso in una panoramica come questa. Considerando che è la prima linea di difesa della tua applicazione, è importante ottenere l'autenticazione dell'utente giusta. Di conseguenza, la soluzione migliore è utilizzare un modulo di autenticazione ben collaudato e ben supportato che esiste già, piuttosto che crearne di nuovi. Se decidi di continuare a scrivere da solo, allora dovresti almeno pubblicare il tuo codice su codereview.stackexchange.net in seguito.

    
risposta data 01.11.2017 - 11:03
fonte
2

Alcune note, se non una risposta completa:

  1. NON usare un semplice hash come SHA-x per i propri hash della password. DEVI usare un hash lento progettato per l'archiviazione delle password.
  2. Se usi correttamente un hash per le password, il tuo doppio hash non aggiunge molto alla sicurezza. In effetti, probabilmente ti sarebbe servito meglio semplicemente aumentando il numero di round del tuo hash della password.
  3. Se per l'utilizzo del sistema è richiesto l'indirizzo e-mail o se viene utilizzato l'indirizzo e-mail per il ripristino della password, è necessario effettuare la verifica e-mail anziché facoltativa. In caso contrario, gli utenti malintenzionati potrebbero iscrivere altri persone (o impedire ad altre persone di creare un account) e gli utenti legittimi potrebbero digitare il loro indirizzo e-mail facendo in modo che qualcun altro sia in grado di ottenere il controllo del proprio account per errore.
risposta data 01.11.2017 - 16:11
fonte

Leggi altre domande sui tag