Il mio sistema di autenticazione senza password (link magico OTPW) è sicuro? [duplicare]

Naviga le tue risposte
3

Ho implementato un sistema di autenticazione senza password (dove gli utenti effettuano il login solo usando un "link magico" inviato alla loro email) da solo. So che progettare sistemi di sicurezza senza esperienza è davvero pessimo, quindi chiedo di sapere se il mio sistema ha buchi evidenti. Ecco come funziona:

  1. L'utente digita la sua email e amp; un nome utente univoco nel client JS (SPA)
  2. L'email e l'amp; il nome utente viene inviato al mio server API (in GET / stringa di query)
  3. Il server API consulta il database degli utenti (vedi sotto per la progettazione di questo DB) per vedere se l'email esiste già
  4. In caso contrario, l'email viene aggiunta al database degli utenti insieme al nome utente (nuovo utente)
  5. Se lo fa, il server API assicura che il nome utente corrisponda all'email, altrimenti risponde con un errore
  6. Il server API genera un GUID ad alta entropia (stringa lunga e casuale) e lo memorizza nel database degli utenti (nella stessa riga dell'email e del nome utente)
  7. Il server API invia all'utente un collegamento contenente il GUID in una stringa di query a una route speciale '/ auth /'
  8. Il server API memorizza l'ora esatta in cui questa email è stata inviata nel database degli utenti
  9. Se il collegamento non è stato premuto entro 30 minuti da quel momento, il GUID viene rimosso dal database degli utenti (quindi l'utente deve accedere nuovamente a)
  10. Se il collegamento è stato premuto nel tempo, il server API genera un nuovo GUID di sessione, lo memorizza nel Database utenti e amp; inserisce un cookie scambiato in tutte le richieste future (ad esempio ogni volta che si verifica una nuova richiesta, il server API assicura che il GUID della sessione corrisponda a quello nel database degli utenti, a indicare che sono connessi)
  11. Il GUID della sessione viene rimosso dal database degli utenti se l'utente decide di disconnettersi
  12. Anche il GUID della sessione viene rimosso ogni 3 giorni (quindi gli utenti devono accedere ogni 3 giorni)

Il database utenti presenta le seguenti colonne, con username come chiave primaria:

| username | email | magic_link_guid | magic_link_guid_date | session_guid | session_guid_date |

Alcuni problemi che non so come risolvere:

  1. Viene effettuata una chiamata al database per ogni richiesta, che non può essere buona
  2. La gestione dei ruoli utente sarebbe davvero difficile con questo metodo
  3. Questo sembra suscettibile agli attacchi XSS / CRSF

Ancora una volta, so che il mio sistema non funziona correttamente, ma non riesco a trovare un sistema priva di password pronto per .NET / C #: (.

    
posta Biarity 18.12.2016 - 07:20
fonte

1 risposta

2

Quello che descrivi è un sistema di autenticazione token . Non è così male, e come è stato detto nei commenti è un modo comune per implementare una funzione password dimenticata .

Alcune applicazioni ben note come redmine offrono nativamente un tale sistema di autenticazione per facilitare l'implementazione di operazioni automatiche utilizzando un'API.

Un problema è la durata del token che viene chiamato il GUID della sessione . Qui costringi l'utente a collegarsi almeno ogni tre giorni, il che è molto intenso. Se è per motivi professionali, i dipendenti sono generalmente autorizzati a prendere ferie più a lungo di 3 giorni, e per mansioni non professionali farlo ogni 3 giorni è entusiasmo (dal badge d'argento nella rete SE per visitare un sito per 30 giorni consecutivi). Cosa deve fare un utente per una traccia in montagna senza accesso alla rete? Ciò significa che dovrai usare intensivamente la generazione di password che si basa solo su username + email che non è abbastanza sicuro per un uso generalizzato. Ma sai anche che più il GUID di sessione viene utilizzato, maggiore è il rischio di essere rubati.

Un altro punto debole è la gestione di un lato client cookie permanente per memorizzare il token. Questo è più o meno memorizzare una password in chiaro sul client, che è noto per essere cattivo. Questo da solo dovrebbe spaventare qualsiasi utente attento alla sicurezza. Ad esempio in redmine, il token viene generato e archiviato nell'app e l'utente ne ha generato uno appena prima di utilizzarlo per le sue richieste API.

Ora per le tue domande:

  • Viene effettuata una chiamata al database per ogni richiesta, che non può essere buona

    Nessun problema qui. I cache sono pensati per mitigare quel problema. Non provate nemmeno a farlo a mano ma affidatevi solo a una cache ben nota. Inoltre, quando parli di un lato client del browser, puoi semplicemente fare affidamento su sessioni HTTP (o HTTPS) una volta che un utente è autenticato

  • Gestire i ruoli utente sarebbe davvero difficile con questo metodo

    I ruoli utente non devono essere gestiti lato client. Dovresti avere una tabella che descriva i ruoli consentiti a un utente: User_ID | Role_ID . Quando trovi un utente, cerchi i suoi ruoli e li memorizza lato server nella sessione. Oppure fai affidamento sulla cache se usi un'API non connessa.

  • Questo sembra suscettibile agli attacchi XSS / CRSF

    Potrebbe o meno essere un problema. Ma dovresti almeno assicurarti che il token cookie sia associato solo al tuo dominio! E si basano anche su metodi di mitigazione comuni sui moduli.

TL / DR: questo è un sistema di autenticazione token. Può essere utilizzato come complemento di un sistema di autenticazione principale ma presenta gravi punti deboli nelle implementazioni descritte se usato da solo. Al contrario, le domande rimanenti non sono realmente un problema e possono essere risolte nel modo comune.

    
risposta data 18.12.2016 - 10:48
fonte

Leggi altre domande sui tag

Sovrascrivi file nella cache del browser È possibile utilizzare CMP (Certificate Management Protocol) per emettere certificati su dispositivi mobili?