Les meilleures pratiques autour de génération de jetons d'authentification OAuth?

Question

Je me rends compte que la OAuth spec ne précise rien sur l'origine de la ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret, ou le Vérificateur de code, mais je suis curieux de savoir si il ya des meilleures pratiques pour la création de manière significative des jetons sécurisés (surtout Jeton/combinaisons Secrètes).

Comme je le vois, il ya quelques approches pour créer les jetons:

1. Utilisez simplement octets aléatoires, magasin en DB associés à des consommateurs/utilisateurs
2. Hachage de l'utilisateur/consommateur de données spécifiques, magasin en DB associés à des consommateurs/utilisateurs
3. Chiffrer l'utilisateur/consommateur de données spécifiques

Avantages (1) est la base de données est la seule source de l'information qui semble le plus sûr. Il serait plus difficile d'exécuter une attaque contre que (2) ou (3).

Le hachage des données réelles (2) permettrait de re-générer le jeton de sans doute déjà connu des données. Peut pas vraiment fournir des avantages de (1) depuis aurais besoin de stocker/recherche de toute façon. Plus de CPU que (1).

Chiffrement des données réelles (3) permet le décryptage de connaître des informations. Cela nécessiterait moins d'espace de stockage et potentiellement moins de recherches que (1) et (2), mais potentiellement moins sûr.

Existe-il d'autres approches / avantages / inconvénients qui doivent être pris en compte?

EDIT: une autre considération est qu'il DOIT y avoir une sorte de valeur aléatoire dans les Jetons qu'il doit exister de la capacité d'expiration et de la réédition de nouveaux jetons de sorte qu'il ne doit pas être uniquement composé de données réelles.

Suivez Sur Les Questions:

Il y a un minimum Jeton de longueur sensiblement cryptographique sécurisé? Si je comprends bien, plus de Jeton Secrets créer plus sûr de signatures. Est-ce la compréhension correcte?

Existe-il des avantages à utiliser un codage particulier sur l'autre, d'un point de vue de hachage? Par exemple, je vois beaucoup d'Api en utilisant un encodage hexadécimal (par exemple, GUID de chaînes de caractères). Dans le OAuth algorithme de signature le Jeton est utilisé comme chaîne de caractères. Avec une chaîne hexadécimale, le jeu de caractères disponibles serait beaucoup plus petite (plus prévisible) que de dire avec un encodage Base64. Il me semble que pour les deux chaînes de longueur égale, celui avec le plus grand jeu de caractères aurait mieux/plus large de hachage de la distribution. Il me semble qu'il permettrait d'améliorer la sécurité. Cette hypothèse est correcte?

OAuth spec soulève cette question dans 11.10 Entropie de Secrets.

Answer 1

OAuth ne dit rien à propos de jeton sauf qu'il a un secret associé avec elle. Donc tous les régimes que vous avez mentionné serait de travailler. Notre jeton évolué comme les sites des plus grands. Voici les versions que nous avons utilisé avant,

1. Notre premier jeton est crypté BLOB avec le nom d'utilisateur, un jeton de secret et d'expiration, etc. Le problème est qu'on ne peut révoquer jetons sans enregistrement sur l'ordinateur hôte.

2. Nous avons donc changé à tout stocker dans la base de données et le jeton est tout simplement un nombre aléatoire utilisé comme clé de la base de données. Il a un nom d'index de sorte qu'il est facile de la liste de tous les jetons pour un utilisateur et de le supprimer.

3. Nous obtenons bien quelques activités de piratage. Avec le nombre aléatoire, nous devons passer d'une base de données pour savoir si le jeton est valide. Nous sommes donc retournés à chiffrées BLOB de nouveau. Cette fois, le jeton contient seulement une valeur chiffrée de la clé et la date d'expiration. Donc, nous pouvons détecter les non valide ou expiré jetons sans passer par la base de données.

Certains détails de mise en œuvre qui peuvent vous aider,

1. Ajouter une version dans le jeton de sorte que vous pouvez jeton changement de format sans casser existants. Tous nos jeton a le premier octet comme version.
2. L'utilisation de l'URL-sûr de la version de Base64 pour coder le BLOB de sorte que vous n'avez pas à traiter avec l'URL problèmes de codage, ce qui rend le débogage plus difficile avec OAuth signature, parce que vous pouvez voir triple codé basestring.