Sistema di authentication a due fattori

Sto cercando di progettare un sistema di authentication a due fattori (su PHP) utilizzando SMS come secondo metodo di authentication. Questo è per un progetto di test, quindi qualcuno può aiutarmi a progettare questo servizio?

Questo sarà un sistema basato sul web e di seguito è quello che ho fatto finora.

  1. Una volta che il cliente inserisce Username e Password, il sito Web invierà al nostro server una richiesta HTTP sicura con MSISDN, un UID (per identificare la session), il loro UserID e PassWord.

  2. Il nostro server aggiungerà la richiesta a un DB MySQL e risponderà al sito web con un codice, UID e alcune altre informazioni.

  3. Il nostro server invierà al client un SMS con la sola password.

  4. Una volta che il client inserisce l'OTP nel sito Web, il sito Web invierà un'altra richiesta HTTPS con l'OTP crittografato al nostro server e invieremo un codice di esito positivo o negativo come risposta.

questo è il stream a cui ho pensato. Qualcuno ha un stream migliore? o suggerimenti?

Grazie.

Sembra un meccanismo valido. Ma cosa succede se il dispositivo SMS non si trova in un'area di servizio? O batteria scarica?

Questo può funzionare bene, tuttavia non è l'authentication a due fattori .

Oltre a una password, un secondo fattore può essere:

  • Qualcosa che hai (es. Secureid, smartcard, ecc.).
  • Qualcosa che sei (cioè varie forms di biometria).

Dal momento che presumo che tu non stia mirando alla biometria;), mi permetta di chiarire perché dico che questo non è un secondo fattore (qualcosa che hai).

Per qualificarsi come secondo fattore, è necessario garantire che il titolare del dispositivo (ovvero il cellulare pre-registrato) sia l' unico che potrebbe aver ricevuto l'SMS.
Nelle reti cellulari di oggi, non è così. Ci sono hack per copiare ad esempio una SIM card; gli operatori cellulari possono intercettare; gli smartphone possono avere app che intercettano e si rinviano; eccetera.
Inoltre, se l'utente digita nuovamente il codice nel sito Web, consente tutti gli attacchi Web standard su tale password aggiuntiva: sniffing, intercettazione, MITM, session hijacking, ecc …

Ora, per essere chiari, questo ha sicuramente un valore – la comunicazione fuori banda può aiutare a garantire che l'utente apparente non venga vittimizzato da un semplice attacco Web, XSS, ecc.
Ho lavorato con molte aziende di telecomunicazioni che amano questa soluzione (è anche parte del loro model di business, ma qualunque sia;))

Tuttavia, a seconda della situazione, alcuni luoghi (ad es. Banche, governo) richiedono un secondo fattore reale, ovvero la prova crittografica (di solito). E questo non lo è.

Vorrei solo aggiungere che l'invio di OTP via SMS è ancora considerato l'authentication a due fattori. Il commento di Avid è chiaro

2 ° fattore, è necessario garantire che il titolare del dispositivo (ovvero il cellulare pre-registrato) sia l'unico che potrebbe aver ricevuto l'SMS.

Ma, lo stesso si applica, ad esempio, per un token hardware basato su 2FA. Come si può garantire che il token hardware sia utilizzato da una sola persona? Rubare un dongle (o cercare l'OTP sullo schermo) è ancora più facile che intercettare SMS

@megazoid, hai considerato di utilizzare i provider "2FA come servizio"? Ad esempio Authy.com , Token2.com o DuoSecurity ?

A tutti piace ancora gli SMS, ma a mio parere fa schifo. Indipendentemente dalla quantità di passcode SMS che tenta di migliorare il stream di lavoro.

Un utente malintenzionato potrebbe richiedere un SMS e intercettare l'SMS senza che l'utente se ne accorga. Per questo non ha nemless bisogno di rubare il telefono. E secondo me questo è il peggior attacco, dal momento che la vittima non si renderà conto che è stato compromesso.

Quando ruba un dongle, l'utente sa che è stato compromesso e che è ansible eseguire le contromisure pertinenti.

Rubare il seme del dongle dal venditore è un vector di attacco molto migliore, che è stato anche mostrato in passato 😉

Questo è il motivo per cui dovresti pensare all'uso di token hardware, che puoi seminare te stesso. Quindi puoi essere sicuro che il seme appartiene solo a te. I token seed sono yubikey, eToken Pass e eToken NG OTP.

Ad each modo, per un ambiente "a bassa sicurezza" anche l'uso degli SMS potrebbe essere ok. Ma devi essere consapevole delle conseguenze. A proposito, tutti quei tipi di token sono supportti dal progetto open source privacyIDEA .

Ti invito a cercare idee nei clienti che abbiamo aperto presso Duo per il nostro sistema di authentication a due fattori:

https://github.com/duosecurity/duo_web

Un altro posto where guardare sono i protocolli di authentication di terze parti esistenti come OAuth e OpenID.

Due cose che non hai menzionato:

  • La risposta firmata dovrebbe includere un ID utente, per il confronto con l'utente locale (probabilmente memorizzato in una session sicura) per evitare replay
  • La risposta firmata dovrebbe includere una scadenza o restituire un nonce indicato nella richiesta firmata

Ricky di Twilio qui.

Abbiamo appena pubblicato un tutorial di Autenticazione a due fattori non banale e pronto per la produzione che puoi verificare se stai cercando qualche ispirazione su come progettare un sistema come questo.