Meilleures pratiques pour générer des jetons OAuth?
Je me rends compte que le spécification OAuth ne spécifie rien sur l'origine du code ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret ou Verifier, mais je suis curieux de savoir s'il existe des meilleures pratiques pour la création jetons considérablement sécurisés (en particulier les combinaisons jeton/secret).
À mon avis, il existe quelques approches pour créer les jetons:
- Utilisez simplement des octets aléatoires, stockez-les dans la base de données associée au consommateur/utilisateur
- Hachage de certaines données spécifiques à l'utilisateur/consommateur, stockées dans la base de données associée au consommateur/utilisateur
- Chiffrer les données spécifiques aux utilisateurs/consommateurs
Les avantages de (1) sont que la base de données est la seule source d'information qui semble la plus sécurisée. Il serait plus difficile de lancer une attaque contre que (2) ou (3).
Le hachage de données réelles (2) permettrait de recréer le jeton à partir de données probablement déjà connues. Pourrait ne pas vraiment fournir d'avantages à (1) car il faudrait de toute façon stocker/rechercher. Plus gourmand en CPU que (1).
Le chiffrement de données réelles (3) permettrait de déchiffrer pour connaître les informations. Cela nécessiterait moins de stockage, potentiellement moins de recherches que (1) (2), mais potentiellement moins sécurisé également.
Y a-t-il d'autres approches/avantages/inconvénients à considérer?
EDIT: une autre considération est qu'il DOIT y avoir une sorte de valeur aléatoire dans les jetons car il doit exister la possibilité d'expiration et de réémettre de nouveaux jetons donc il doit ne pas être uniquement composé de données réelles.
Questions complémentaires :
Existe-t-il une longueur minimale de jeton pour sécuriser de manière significative sur le plan cryptographique? Si je comprends bien, des Token Secrets plus longs créeraient des signatures plus sécurisées. Cette compréhension est-elle correcte?
Y a-t-il des avantages à utiliser un encodage particulier par rapport à un autre du point de vue du hachage? Par exemple, je vois beaucoup d'API utilisant des encodages hexadécimaux (par exemple GUID chaînes). Dans l'algorithme de signature OAuth), le jeton est utilisé comme une chaîne. Avec une chaîne hexadécimale, le jeu de caractères disponible serait beaucoup plus petit (plus prévisible) qu'avec un encodage Base64. Il me semble que pour deux chaînes de même longueur, celle avec le plus grand jeu de caractères aurait un hachage meilleur/plus large Il me semble que cela améliorerait la sécurité. Cette hypothèse est-elle correcte?
La spécification OAuth soulève ce problème dans 11.10 Entropy of Secrets .
OAuth ne dit rien sur le jeton, sauf qu'il a un secret qui lui est associé. Donc, tous les régimes que vous avez mentionnés fonctionneraient. Notre jeton a évolué à mesure que les sites s'agrandissaient. Voici les versions que nous avons utilisées auparavant,
Notre premier jeton est un BLOB chiffré avec nom d'utilisateur, secret de jeton et expiration, etc. Le problème est que nous ne pouvons pas révoquer des jetons sans aucun enregistrement sur l'hôte.
Nous l'avons donc changé pour tout stocker dans la base de données et le jeton est simplement un nombre aléatoire utilisé comme clé de la base de données. Il a un index de nom d'utilisateur, il est donc facile de répertorier tous les jetons d'un utilisateur et de le révoquer.
Nous obtenons assez peu d'activités de piratage. Avec un nombre aléatoire, nous devons aller dans la base de données pour savoir si le jeton est valide. Nous sommes donc retournés au BLOB crypté. Cette fois, le jeton ne contient que la valeur chiffrée de la clé et l'expiration. Nous pouvons donc détecter des jetons invalides ou expirés sans aller dans la base de données.
Quelques détails d'implémentation qui peuvent vous aider,
- Ajoutez une version dans le jeton pour pouvoir modifier le format du jeton sans casser les versions existantes. Tous nos jetons ont d'abord un octet comme version.
- Utilisez une version sécurisée URL de Base64 pour encoder le BLOB afin de ne pas avoir à traiter les problèmes de codage d'URL, ce qui rend le débogage plus difficile avec la signature OAuth, car vous pouvez voir un triple encodage basestring.