Produits Entr'ouvert » Authentic 2

Aussi, ça permet bien sûr à un tiers d'être carrément chiant.

Extra fun sur les comptes utilisés pour accéder aux API.

Les comptes d'accès aux APIs ne devraient pas avoir d'email, ensuite c'est un comportement habituel pour permettre immédiatement de retirer l'accès à un compte en cas de vol de mot de passe que de rendre celui-ci inutilisable dés la demande de ré-initialisation. Coté bancaire c'est systématique, peut-être que Google et Facebook ne le font pas je n'en sais rien.

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

Step 2) Verify Security Questions

After the form on Step 1 is submitted, the application verifies that each piece of data is correct for the given username. If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers. It’s important that the answer fields are part of a single HTML form.

Do not provide a drop-down list for the user to select the questions he wants to answer. Avoid sending the username as a parameter (hidden or otherwise) when the form on this page is submitted. The username should be stored in the server-side session where it can be retrieved as needed.

Because users' security questions / answers generally contains much less entropy than a well-chosen password (how many likely answers are there to the typical "What's your favorite sports team?" or "In what city where you born?" security questions anyway?), make sure you limit the number of guesses attempted and if some threshold is exceeded for that user (say 3 to 5), lock out the user's account for some reasonable duration (say at least 5 minutes) and then challenge the user with some form of challenge token per standard multi-factor workflow; see #3, below) to mitigate attempts by hackers to guess the questions and reset the user's password. (It is not unreasonable to think that a user's email account may have already been compromised, so tokens that do not involve email, such as SMS or a mobile soft-token, are best.)

Step 3) Send a Token Over a Side-Channel

After step 2, lock out the user's account immediately. Then SMS or utilize some other multi-factor token challenge with a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the side-channel. It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so. That way if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the "reset password" token was discovered by an attacker. Of course, by all means, once a user's password has been reset, the randomly-generated token should no longer be valid.

Je reconnais qu'on a pas l'étape 2.

... peut-être que Google et Facebook ne le font pas je n'en sais rien.

Et bien sûr je ne vais vérifier ni l'un ni l'autre; et je n'ai pas d'authentification par mot de passe auprès de ma banque, mais j'ai testé quelques sites communs sur lesquels j'ai des comptes et aucun ne fait ça. Le seul s'approchant, c'est amazon qui est tout différent et après ce formulaire "mot de passe perdu" demande à l'usager de choisir entre créer un nouveau mot de passe et se connecter avec un code temporaire.

Je maintiens que le comportement d'authentic est devenu inhabituel et si pas dangereux, relativement perturbant quand même.

Frédéric Péters a écrit :

Je maintiens que le comportement d'authentic est devenu inhabituel et si pas dangereux, relativement perturbant quand même.

Même avis : ça permet à n'importe qui de coincer n'importe quel compte, ça me parait bien étrange. Un peu comme le site de notre banque qui bloque le compte après 3 tentatives ratées : n'importe qui peut venir nous faire chier s'il connait notre login d'accès (et pour le coup, ça ferai chier 24 à 48h).

Paul Marillonnet a écrit :

[...] tokens that do not involve email, such as SMS or a mobile soft-token, are best.

Ce serait faisable dans authentic ?

Tout est possible, mais je ne vois pas pourquoi tu mets une note privée :)

Comme je ne suis pas pour je vous propose de faire un patch (c'est une ligne dans registration pour mettre reset_password=False sur l'appel d'envoi du mail).

Et effectivement OWASP prévoit le problème puisqu'ils demandent d'ajouter des questions de sécurité avant d'accepter la demande de reset, faut juste ne pas rendre le type de question dépendante de la personne sinon on gagne un oracle pour savoir si un email est dans la base.

Ok pour le patch.