web-dev-qa-db-fra.com

Empêcher les abus OTP dans le flux d'inscription des applications

Cela peut sembler une question ouverte, mais je voudrais tenter ma chance et comprendre s'il existe un moyen pour le reste de la communauté de gérer ce problème.

Disons qu'il existe une application qui permet aux utilisateurs de s'inscrire en utilisant leur numéro de téléphone.

Plateforme d'application

  1. Android
  2. iOS

Flux d'application

  1. l'utilisateur ouvre l'application
  2. il est présenté avec un utilisateur de bouton de connexion/enregistrement
  3. veut maintenant s'inscrire car il est un nouvel utilisateur. Alors il clique sur le bouton d'inscription et on lui demande son numéro de téléphone
  4. lorsqu'il communique son numéro de téléphone, il reçoit un OTP par SMS. Supposons que l'application appelle réellement le /register API qui est celle qui déclenche le SMS.

Risque: Maintenant, pour chaque SMS sortant, il y a un coût financier impliqué.

Mesures d'atténuation proactives/réactives

  1. L'API est à taux limité (basé sur le numéro de téléphone)
  2. Une surveillance et une alerte adéquates sont en place. Donc, s'il y a des cas d'abus, des mesures extrêmes comme le blocage IP peuvent se produire.

Problèmes

  1. Si un adversaire (potentiellement un concurrent) frappe l'API avec des numéros de téléphone différents, la logique de limitation de débit est facilement contournée.
  2. Le blocage IP peut ne pas être viable tout le temps. Supposons que l'adversaire se trouve derrière un réseau NAT, tous les utilisateurs authentiques derrière le réseau sont également empêchés d'effectuer une inscription réussie.
  3. Si l'adversaire change d'IP (peut-être en utilisant Tor), l'étape d'atténuation 2 mentionnée ci-dessus est également contournée.
  4. Captcha n'est pas une solution car il détruit l'UX, en particulier lorsqu'il s'agit d'applications mobiles.
  5. Avoir un mot de passe de nom d'utilisateur au lieu d'OTP pour la vérification de l'enregistrement n'est pas une option car l'application a besoin d'un numéro de téléphone vérifié pour fonctionner.
  6. La signature par périphérique peut également être utilisée comme facteur pour évaluer la limite, mais le fait est que cela provient également du périphérique via HTTP (s). Par conséquent, facilement modifiable également. Cette option est donc également exclue.

Dans une telle situation, comment se protéger contre le risque ou peut-être planifier et s'y préparer, s'il ne peut pas du tout être trié?

one-time-passwordsmsregistration
11
qre0ct

La vérification des e-mails d'abord

Si votre UX le permet, vous pouvez demander à l'utilisateur de créer d'abord un compte en fonction de son adresse e-mail. Une fois l'adresse vérifiée, vous pouvez autoriser l'ajout d'un numéro de téléphone, puis le vérifier à votre manière habituelle.

Un utilisateur légitime a probablement déjà une adresse e-mail et la configuration reste donc simple. Cependant, un attaquant devrait créer une nouvelle boîte aux lettres fonctionnelle (ou alias) pour chaque tentative. En limitant le taux/max de la vérification du téléphone par domaine de messagerie, vous vous assurez qu'ils ne peuvent pas automatiser cela facilement. Les services de messagerie gratuits empêchent généralement déjà la création de compte automatisée, et vous pouvez mettre sur liste noire ceux qui ne le font pas.

Utilisez des CAPTCHA invisibles

Il existe des CAPTCHA qui ne nécessitent aucune interaction utilisateur que vous pouvez également utiliser lors de votre intégration, par exemple: https://developers.google.com/recaptcha/docs/invisible

5
Jens Ehrich

Malheureusement, il n'y a pas de moyen solide d'obtenir le numéro de téléphone sans OTP. Cependant, vous pouvez obtenir le deviceID () du téléphone Android. Cela vous donnera un numéro IMEI valide. Tout d'abord, vérifiez ce numéro avec un de vos serveurs et voyez s'il y a quelque chose de louche à ce sujet .

Vous pouvez également utiliser d'autres données de manière anonyme. Par exemple, si votre application utilise les autorisations READ_CONTACTS ou READ_PROFILE, vous pouvez utiliser les données qui s'y trouvent pour identifier les faux utilisateurs. (Par exemple, le téléphone n'a que des applications de démarrage, le même IMEI mais continue d'envoyer des numéros de sms différents.)

1
user176142
  1. Ensuite, vous devez limiter la vitesse par IP (voir 2)
  2. Ensuite, vous devez choisir une limite qui a du sens (par exemple; quelle est la probabilité que vous obteniez 10 enregistrements de la même adresse IP en une heure? Ou peut-être 1000 par jour?). Prenez un nombre raisonnable par intervalle, ajoutez un petit plus pour être prudent (mais aussi en respectant le budget)
  3. Vous pouvez bloquer les IP TOR/Proxy/VPN. Si vous ne le souhaitez pas, vous pouvez évaluer la limite de ces IP avec des limites différentes (plus strictes) (voir également 4)
  4. Il y a non-intrusif (ou moins ennuyeux) captcha que les textes ondulés floues arrosant les yeux. Aussi; vous ne pouviez afficher les captcha que sur les IP TOR/Proxy/VPN
  5. -
  6. Vous ne pouvez pas faire confiance aux données client. Ne faites jamais confiance aux données client.

Il existe des bases de données de nœuds de sortie de proxy et de TOR connus (ouverts). Certains sont plus fiables que d'autres, mais ils ont également un coût (bien qu'il existe des bases de données gratuites disponibles).

Aussi; selon le volume, il y aura forcément des faux positifs/négatifs. Acceptez le fait que vous n'obtiendrez jamais ce 100% correct. Fournissez donc un moyen aux utilisateurs légitimes d'obtenir de l'aide/de s'inscrire d'une autre manière s'ils sont identifiés comme illégitimes ou injustifiés. Fournissez également un moyen facile pour vous/quiconque gère le site Web/service d'ajouter (et de supprimer) des adresses IP (ou des numéros de téléphone) à (ou à partir de) une liste noire qui NE DOIT PAS être signalée mais devrait l'être.

1
RobIII

Il y a quelques choses que je ferais pour augmenter l'atténuation des risques.

  1. Ne pensez pas que le Captcha est toujours allumé ou toujours éteint. Activez-le en fonction du taux de tentatives par adresse IP. Considérez-le comme quelque chose comme une liste grise. Il est probablement préférable d'affecter l'UX que de le bloquer entièrement. Vous pouvez ensuite envisager d'autres blocs (liste noire IP totale par exemple) en fonction du captcha échoué/des taux plus élevés.

  2. Quelles que soient les mesures d'atténuation que vous mettiez en place, vous aurez des solutions de contournement ou des modes d'attaque que vous n'avez pas pris en compte par des attaquants dédiés, vous avez donc besoin de quelque chose en place pour vous protéger/alerter contre cette possibilité. Vous devriez envisager de placer une limite de taux sur le SMS pour ne permettre qu'un certain montant par unité de temps, ou potentiellement alerter les membres du personnel de répondre à une telle attaque lorsque les coûts atteignent un certain seuil .

    Cela vous protégerait davantage contre les bogues dans le logiciel lui-même qui pourraient générer des boucles, des doublons, etc. et envoyer de grandes quantités de messages SMS SMS erronés, plutôt que de simples attaques malveillantes et intentionnelles.

1
Steve Sether