Previene l'abuso di OTP nel flusso di registrazione dell'app

2

Potrebbe sembrare una domanda a risposta aperta, ma mi piacerebbe cogliere le mie possibilità e capire se c'è un modo in cui il resto della community sta gestendo questo problema.

Diciamo che c'è un'app che consente agli utenti di registrarsi utilizzando il loro numero di telefono.

Piattaforma di app

  1. Android
  2. iOS

Flusso di app

  1. utente apre l'app
  2. viene presentato con un utente di login / pulsante di registrazione
  3. ora vuole registrarsi perché è un nuovo utente. Quindi fa clic sul pulsante di registrazione e gli viene richiesto il suo numero di telefono
  4. quando invia il suo numero di telefono, riceve un OTP via SMS. Supponiamo che l'app in effetti chiami l'API /register che è quella che attiva lo SMS.

del rischio: Ora per ogni SMS in uscita, c'è un costo finanziario.

Misure di mitigazione proattiva / reattiva

  1. L'API è a tasso limitato (in base al numero di telefono)
  2. C'è un monitoraggio e un avviso adeguati. Quindi, se ci sono casi di abuso, possono verificarsi misure estreme come il blocco IP.

Pubblicazioni

  1. Se un avversario (potenzialmente un concorrente) colpisce l'API con diversi numeri di telefono, la logica di limitazione della velocità è facilmente aggirabile.
  2. Il blocco IP potrebbe non essere sempre valido. Se l'avversario si trova dietro una rete NATed, anche tutti gli utenti autentici dietro la rete vengono bloccati dall'effettuare l'iscrizione con successo.
  3. Se l'avversario cambia IP (magari usando Tor), anche il passaggio di mitigazione 2 sopra menzionato viene aggirato.
  4. Captcha non è una soluzione in quanto distrugge UX, specialmente quando si tratta di app mobili.
  5. Avere la password del nome utente al posto di OTP per la verifica della registrazione non è un'opzione perché l'app necessita di un numero di telefono verificato per funzionare.
  6. La firma del dispositivo può anche essere utilizzata come fattore per limitare il limite, ma il fatto è che viene anche dal dispositivo su HTTP (s). Quindi, facilmente modificabile pure. Quindi anche questa opzione è esclusa.

In una situazione del genere, come proteggersi dal rischio o magari pianificare e prepararsi per questo, se non può essere risolto?

    
posta qre0ct 26.04.2018 - 06:46
fonte

0 risposte

Leggi altre domande sui tag