> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qaos.machdel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Authentification
> Critères dans les mécanismes d'authentification — identifiants par défaut, lacunes de limitation de débit, politiques de mots de passe faibles et jetons de session falsifiés.
Les critères d'authentification permettent aux attaquants de se connecter sous l'identité d'autres utilisateurs, de forcer des comptes par force brute ou de contourner entièrement la connexion. Ces vulnérabilités sont souvent triviales à exploiter et ont des conséquences graves.
***
## default-accounts-present
Critique
**Description**
L'application accepte des identifiants par défaut bien connus qui n'ont jamais été changés après le déploiement. Les valeurs par défaut courantes incluent `admin/admin`, `admin/password`, `root/root` et `admin/1234`.
**Importance**
Les attaquants essaient systématiquement les identifiants par défaut comme première étape de la reconnaissance. Une seule connexion réussie accorde un accès administratif complet sans aucune attaque sophistiquée.
**Comment QAOS le détecte**
Lorsque l'agent rencontre un formulaire de connexion, il tente une authentification avec un ensemble de paires d'identifiants par défaut courants : `admin/admin`, `admin/password`, `root/root`, `admin/1234`.
**Comment corriger**
Forcez le changement d'identifiants à la première connexion pour tout compte créé avec des identifiants par défaut. Supprimez ou désactivez complètement les comptes par défaut en production. Effectuez des audits réguliers pour s'assurer qu'aucun compte avec des identifiants par défaut n'existe.
***
## default-credentials-in-dom
Critique
**Description**
La page elle-même révèle des identifiants par défaut ou d'usine — via du texte d'espace réservé, des champs de formulaire pré-remplis, des commentaires HTML inline, du texte visible ou des sections d'aide sur la page.
**Importance**
Révéler des identifiants dans le DOM signifie que tout utilisateur qui ouvre les DevTools ou consulte le code source de la page peut les voir. Aucune attaque technique n'est requise.
**Comment QAOS le détecte**
L'agent inspecte le DOM pour les indices d'identifiants visibles : attributs placeholder, attributs value pré-remplis sur les champs de connexion, commentaires HTML et texte visible contenant des motifs comme « connexion par défaut », « mot de passe d'usine » ou « utiliser admin/ ».
**Exemples**
```html theme={null}
Première connexion : utiliser admin / admin123
```
**Comment corriger**
Supprimez tous les indices d'identifiants du DOM. Utilisez du texte d'espace réservé générique comme « Nom d'utilisateur » et « Mot de passe ». N'incluez jamais d'identifiants dans les commentaires, le texte d'aide ou les valeurs pré-remplies sur les pages en production.
***
## cookie-token-forgery
Critique
**Description**
Les cookies de session encodent l'identité utilisateur d'une façon qui peut être prédite, décodée ou modifiée pour usurper l'identité d'autres utilisateurs. Cela inclut les IDs utilisateur encodés en base64, les motifs prévisibles ou les simples hachages du nom d'utilisateur.
**Importance**
Si un attaquant peut construire un cookie de session valide pour un autre utilisateur sans connaître son mot de passe, il peut prendre le contrôle de n'importe quel compte sur la plateforme.
**Comment QAOS le détecte**
L'agent analyse les cookies de session et d'authentification pour détecter les valeurs à faible entropie, le contenu encodé en base64, les horodatages, les valeurs purement numériques ou les motifs corrélés avec des identifiants utilisateur connus.
**Exemples**
```
session=dXNlcjEyMw== ← décodage base64 : "user123" — trivialement falsifiable
auth_token=1708473600123 ← horodatage Unix — prévisible
session_id=00001042 ← numérique séquentiel — énumérable
```
**Comment corriger**
Générez des jetons de session en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé avec au moins 128 bits d'entropie. N'encodez jamais l'identité utilisateur directement dans les jetons de session. Utilisez un magasin de sessions côté serveur qui mappe des jetons opaques vers des sessions utilisateur.
```python theme={null}
import secrets
session_token = secrets.token_urlsafe(32) # 256 bits d'entropie
```
***
## no-password-spraying-protection
Élevé
**Description**
Le formulaire de connexion ne protège pas contre les attaques par pulvérisation de mots de passe — où un attaquant essaie un seul mot de passe courant sur de nombreux comptes différents, évitant les verrouillages par compte.
**Importance**
La pulvérisation de mots de passe est l'une des techniques d'attaque par identifiants les plus efficaces car elle reste sous les seuils de verrouillage par compte. Un seul mot de passe courant comme « Été2024! » peut correspondre à un pourcentage significatif des comptes utilisateurs.
**Comment QAOS le détecte**
L'agent teste les formulaires de connexion en essayant le même mot de passe sur plusieurs noms d'utilisateur différents en succession rapide, observant si l'application détecte ou ralentit ce motif.
**Comment corriger**
Implémentez une limitation de débit basée sur l'**IP source et la valeur du mot de passe**, pas seulement le nom d'utilisateur. Surveillez le même mot de passe essayé sur plusieurs comptes. Envisagez un CAPTCHA après un seuil d'échecs depuis une seule IP, quel que soit le nom d'utilisateur ciblé.
***
## no-login-rate-limiting
Élevé
**Description**
Le formulaire de connexion permet des tentatives d'authentification échouées illimitées sans verrouillage, délais progressifs ou défis CAPTCHA.
**Importance**
Sans limitation de débit, les attaquants peuvent effectuer des attaques par force brute ou par bourrage d'identifiants à haute vitesse, devinant éventuellement des identifiants valides.
**Comment QAOS le détecte**
L'agent soumet des tentatives de connexion invalides répétées et observe si l'application répond avec une limitation de débit (HTTP 429, message de verrouillage, délai progressif ou CAPTCHA).
**Comment corriger**
Implémentez un verrouillage par compte après 5 à 10 tentatives échouées. Ajoutez des délais de recul exponentiel pour les échecs répétés. Envisagez un CAPTCHA après 3+ échecs. Journalisez et alertez sur les motifs inhabituels de tentatives de connexion.
***
## compromised-credentials-accepted
Élevé
**Description**
Le formulaire d'inscription ou de changement de mot de passe accepte des identifiants connus pour être compromis dans des violations de données publiques.
**Importance**
Les attaques par bourrage d'identifiants réutilisent des combinaisons nom d'utilisateur/mot de passe divulguées sur plusieurs services. Si votre application ne vérifie pas les mots de passe connus comme compromis, elle est vulnérable aux attaques automatisées utilisant des bases de données de violations.
**Comment QAOS le détecte**
L'agent tente de s'inscrire ou de changer des mots de passe en utilisant des paires d'identifiants compromis bien connus provenant de jeux de données de violations publiques.
**Comment corriger**
Intégrez avec l'[API Have I Been Pwned](https://haveibeenpwned.com/API/v3) (modèle k-anonymat) pour vérifier les mots de passe par rapport aux bases de données de violations connues lors de l'inscription et du changement de mot de passe. Rejetez les mots de passe compromis et invitez l'utilisateur à en choisir un différent.
***
## weak-password-accepted
Moyen
**Description**
Le système d'authentification accepte des mots de passe faibles — moins de 8 caractères, ou des mots de passe courants comme `123456`, `password` ou `abc`.
**Importance**
Les mots de passe faibles sont trivialement devinables par les attaquants humains et les outils automatisés. Les accepter crée des comptes facilement compromis.
**Comment QAOS le détecte**
L'agent tente de s'inscrire ou de changer des mots de passe en utilisant des valeurs de test faibles : `123456`, `password`, `abc` et d'autres motifs courants.
**Comment corriger**
Imposez une longueur minimale de mot de passe de **8 caractères** (12+ recommandé). Rejetez les mots de passe courants. Envisagez d'utiliser [zxcvbn](https://github.com/dropbox/zxcvbn) pour l'estimation de la robustesse plutôt que de simples règles de longueur.
***
## knowledge-based-password-recovery
Élevé
**Description**
Le flux de récupération de mot de passe repose sur des questions de connaissance personnelle — telles que « le nom de jeune fille de la mère », « le nom du premier animal de compagnie » ou « la ville de naissance » — pour vérifier l'identité avant de permettre une réinitialisation de mot de passe.
**Importance**
Les réponses aux questions de sécurité sont souvent disponibles publiquement via les réseaux sociaux, les violations de données ou l'ingénierie sociale. Elles offrent une garantie d'authentification beaucoup plus faible que la vérification par email ou SMS, et ne peuvent pas être changées une fois compromises.
**Comment QAOS le détecte**
L'agent navigue vers le flux de mot de passe oublié ou de récupération de compte et vérifie s'il demande des questions de connaissance personnelle avant d'accorder l'accès ou d'initier une réinitialisation.
**Comment corriger**
Remplacez la récupération basée sur la connaissance par un jeton à durée limitée et à usage unique envoyé à un email ou numéro de téléphone vérifié. Pour les applications à haute assurance, exigez que l'utilisateur confirme son identité via MFA avant de réinitialiser les identifiants.
***
## insecure-password-reset-process
Élevé
**Description**
Le processus de réinitialisation de mot de passe est vulnérable — le jeton de réinitialisation est prévisible, n'expire pas ou peut être rejoué. Un attaquant qui intercepte ou devine un jeton de réinitialisation peut prendre le contrôle du compte sans connaître le mot de passe original.
**Importance**
Les flux de réinitialisation de mot de passe sont des cibles de haute valeur car ils contournent l'identifiant principal. Un processus de réinitialisation faible supprime effectivement la sécurité du mot de passe entièrement.
**Comment QAOS le détecte**
L'agent déclenche le flux de réinitialisation de mot de passe et inspecte le jeton de réinitialisation pour sa prévisibilité (séquentiel, court, basé sur un horodatage). Il teste également si le jeton peut être réutilisé après la réinitialisation.
**Comment corriger**
Générez des jetons de réinitialisation en utilisant un générateur aléatoire cryptographiquement sécurisé avec au moins 128 bits d'entropie. Expirez les jetons après 15 à 60 minutes. Invalidez le jeton immédiatement après sa première utilisation. Assurez-vous que les jetons sont limités à un utilisateur spécifique et ne peuvent pas être transférés.
```python theme={null}
import secrets
token = secrets.token_urlsafe(32) # jeton 256 bits, compatible URL
```
***
## missing-mfa-sensitive-actions
Élevé
**Description**
Les actions sensibles — telles que le changement de mot de passe, la mise à jour des détails de paiement, le transfert de fonds ou la modification des paramètres de récupération de compte — se complètent après une authentification par mot de passe uniquement, sans deuxième facteur requis.
**Importance**
Si un attaquant accède à la session d'un utilisateur (via XSS, détournement de session ou un appareil compromis), il peut effectuer des actions à fort impact sans aucune barrière supplémentaire. Le MFA sur les actions sensibles limite les dommages d'une session compromise.
**Comment QAOS le détecte**
L'agent identifie les flux pour les opérations sensibles (changements d'identifiants, modifications de paiement, paramètres de récupération de compte) et tente de les compléter sans second facteur d'authentification.
**Comment corriger**
Exigez une authentification renforcée (ré-authentification ou défi MFA) avant de compléter les actions à fort impact, même au sein d'une session déjà authentifiée. Les motifs courants incluent :
* Ressaisir le mot de passe actuel avant de le changer
* Exiger un OTP d'une application d'authentification ou SMS avant les changements de paiement
* Envoyer un lien de confirmation par email pour les modifications des coordonnées de récupération
***
## weak-mfa-fallback-mechanism
Élevé
**Description**
Quand le MFA est indisponible (appareil perdu, code de secours expiré), le mécanisme de récupération de secours est faible — il repose sur des questions de connaissance personnelle, un court code statique ou un canal avec une assurance insuffisante — permettant aux attaquants de contourner le MFA entièrement.
**Importance**
Le MFA est seulement aussi fort que son mécanisme de secours le plus faible. Si un attaquant peut contourner le MFA en répondant à une question de sécurité, l'ensemble du second facteur est annulé. Les mécanismes de secours sont fréquemment la vraie cible des attaques de prise de contrôle de compte.
**Comment QAOS le détecte**
L'agent navigue vers la page de défi MFA et explore les options de récupération/secours, vérifiant si elles offrent une assurance équivalente au second facteur principal.
**Comment corriger**
Les mécanismes de secours doivent être au moins aussi forts que la méthode MFA principale :
* Codes de secours : codes à usage unique et à haute entropie générés lors de la configuration MFA
* Récupération de compte : exiger une vérification d'identité via un canal de confiance (lien email + preuve de propriété du compte)
* Récupération assistée par le support : exiger une vérification humaine avec pièce d'identité avec photo ou similaire
Ne jamais permettre le contournement du MFA via des questions de sécurité, de courts PINs statiques ou des flux de récupération non authentifiés.