Implementazione della reimpostazione della password in un'applicazione Web tramite authtoken tramite e-mail

2

Penso di avere una comprensione di base dei problemi di sicurezza, ma mi sento come se non sapessi tutto, implementerò soluzioni pessime. Di seguito è la mia strategia attuale; Ho trascurato le migliori pratiche ovvie?

Ho letto Can qualcuno fornisce riferimenti per implementare correttamente i meccanismi di reimpostazione automatica della password delle applicazioni web e pensa che io abbia le parti interessate coperte.

Flusso

  1. Un amministratore attiva la reimpostazione della password per un utente nel sistema.
  2. Il sistema blocca l'utente dal sistema, genera una stringa alfanumerica casuale di 40 caratteri come authtoken e memorizza questo hash nel database con SHA1, insieme al nome utente crittografato, l'ora è stata creata e l'hash del vecchia password. Se l'utente ha dei token di autenticazione precedenti nel db, li elimina.
  3. Il sistema invia un link all'email connessa all'utente che ha la password attivata per il ripristino.
  4. L'utente fa clic sul link, che si trova su https, e il sistema legge authtoken.
  5. Il sistema lo blocca di nuovo con SHA1, cerca nel database per esso:

    • Il authtoken non corrisponde: pagina di errore. %codice%
    • L'authtoken è stato creato più di 4 ore fa: Please contact admin
    • L'authtoken è stato trovato e attivo: Goto 6
  6. Il client viene presentato un dialogo per selezionare una nuova password e invia la nuova password con lo stesso authtoken (in un campo nascosto) al server.

  7. Il sistema verifica nuovamente che authToken esista, sia attivo e che la password non sia uguale a quella precedente. In caso di successo, il sistema decrittografa il nome utente memorizzato insieme a authtoken, cambia la password per questo utente al nuovo, sblocca l'utente e rimuove authToken dal database.
  8. Il sistema reindirizza l'utente alla pagina di accesso.

Quindi

L'unico agente che attiva il processo di ripristino è un amministratore autenticato: nessun problema con utenti malintenzionati. Tutta la comunicazione tra client e server passa a HTTPS, con l'eccezione possibile e incontrollabile della soluzione email dell'utente.

Ecco come viene generato authToken:

const string authtokenAlphabet =  abcdefghijklmnopqrstuvxyzABCDEFGHIJKLMNOPQRSTUVXYZ1234567890_-.";
const int authtokenSize = 40;
var authToken = string.Empty;

while (authToken.Length < authtokenSize)  
    authToken += authtokenAlphabet[_random.Next(0, authtokenAlphabet.Length - 1)];

Sebbene io usi la classe Please contact admin , che è scoraggiata a causa di una casualità non ottimale, sarebbe davvero un problema considerando che solo un amministratore autorizzato e autenticato può attivare il reset?

    
posta Alex 05.06.2014 - 09:22
fonte

1 risposta

1
  • In 1 questo trigger è protetto da XSRF?
  • In 2 stai bloccando l'account utente per 4 ore? Questo è un DOS

  • In 6 utilizzi un generatore casuale debole. Se qualcuno lo scopre, può generare authToeksn per chiunque.

  • non hai mai menzionato come stai crittografando nomi utente? Pensa alla possibilità di crittografare un nome utente e di inserirlo in authToken Questo porterà a cambiare la password di quel username nel tuo sistema anche se quel username non ha chiesto di impostare una nuova password.

  • Si noti inoltre che authToken proviene dal client. La regola di sicurezza di base è di non fidarsi mai di nulla proveniente dal client, quindi assicurati di disinfettare correttamente questi token da sqli, slqi, ecc. Questo vale anche per new-password !

risposta data 09.06.2014 - 01:19
fonte

Leggi altre domande sui tag