Nous travaillons sur un nouveau projet, nous sommes deux développeurs principaux et nous sommes à la croisée des chemins sur la façon d'utiliser un token pour sécuriser la communication entre le serveur et le client.

Première suggestion: (le jeton statique AKA à jeton unique)

1. le client demande un jeton principal, en envoyant le nom d'utilisateur et le mot de passe et l'heure_courante (cette variable sera enregistrée dans la base de données du serveur et côté client également) à l'api, le serveur interprète l'entrée et rend un jeton haché (par exemple: 58f52c075aca5d3e07869598c4d66648) l'enregistre dans la base de données et le renvoie au client.

2. Le client enregistre maintenant le jeton principal et crée un nouveau jeton haché en utilisant le jeton principal + la variable current_time envoyée dans la demande d'authentification (permet d'appeler ce nouveau jeton, main_token) également le serveur fait de même et crée le même jeton en utilisant le même algorithme .

3. Chaque fois que le client interroge l'API du serveur, il envoie le main_token au serveur, maintenant le serveur compare le jeton généré en lui, avec le main_token envoyé par le client, s'il correspond, cela signifie que l'utilisateur est réel

Deuxième suggestion: (jeton dynamique)

1. Le client génère deux clés aléatoires ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) À chaque demande sur l'API, le client crée un hachage à l'aide du type de requête et les deux clés avec un algorithme complexe, et envoie ces deux clés + le hachage au serveur

2. Le serveur, en utilisant le même algorithme utilisé dans le client, crée un hachage et le compare à celui envoyé par le client, s'il correspond, le serveur continue de traiter la requête

Maintenant, la question est: Laquelle est la façon la plus logique et la plus sûre d'utiliser pour sécuriser les demandes d'API?

J'aime vraiment la première approche en général.

• c'est simple à comprendre et à mettre en œuvre
• c'est sécurisé (à ma connaissance)
• c'est une approche pas rare que j'ai vue utilisée dans le passé

Une chose que je ne vois pas mentionnée à propos de la première que vous devez garder à l'esprit, l'horodatage utilisé pour hacher le jeton doit avoir une expiration TTL qui est extrêmement courte (comme 1 seconde), donc vous vérifiez que le message n'a pas été envoyé avec le même horodatage et jeton d'un message 12 heures plus tôt; évidemment, il serait calculé comme légitime, mais ce n'est pas le cas dans ce cas.

Si ce sont les deux seules options que vous envisagez, je voudrais simplement m'assurer que vous avez également examiné d'autres approches, car il y en a beaucoup. Plus que je ne vais en énumérer en fait. Ce sont des approches d'authentification courantes qui méritent d'être étudiées juste pour voir si elles pourraient mieux convenir à votre objectif, et si rien d'autre les comprendre ne peut vous donner quelques idées pour vous aider à resserrer l'approche que vous choisissez.

Notez que je ne suis pas un expert en sécurité.

OAuth / fédéré

Dans cette approche, vous avez un garant tiers où le code consommateur demande le jeton / certificat / ce que vous avez d'eux et vous le transmet, à ce stade, tout ce que vous devez faire est de demander au tiers si la clé qui vous a été donnée est légitime.

Pro:

• Basé sur des normes
• Des problèmes seront détectés par d'autres sur les systèmes d'autres personnes afin que vous sachiez si l'insécurité se produit
• Beaucoup moins de travail d'authentification sera nécessaire de votre part

Con:

• Vous devez traiter avec un réparateur tiers et son API, ou créer et héberger votre propre «tiers» pour séparer l'authentification de votre service principal.
• Pour de nombreux services exagérés, mais mérite d'être envisagé sur le plan conceptuel

Certificats asynchrones

Ici, vos clients chiffreraient leurs communications avec un certificat public que vous avez partagé avec eux lorsqu'ils ont créé un utilisateur. De votre côté, vous décrypteriez en utilisant la clé privée associée à cet utilisateur. Généralement, vous initieriez la communication avec une réponse de défi pour montrer qu'ils peuvent chiffrer / déchiffrer comme vous vous attendez à les identifier comme qui ils prétendent être. Bien que des approches "synchrones" soient possibles qui n'utilisent pas la réponse-défi, elles ont un peu moins de sécurité et des problèmes de synchronisation temporelle qui peuvent les rendre plus délicats.

de Novell (ouais je sais, novell? vraiment?)

Les jetons utilisent une variable comme base pour générer le mot de passe à usage unique. Cette variable est appelée le défi. Les deux principales méthodes pour déterminer la variable utilisée pour générer le mot de passe sont asynchrones ou synchrones.

Avec la méthode asynchrone ou challenge-response, le logiciel serveur envoie au token un challenge externe --- une variable générée aléatoirement --- pour le périphérique token à crypter. Le jeton utilise cette variable de défi, l'algorithme de chiffrement et le secret partagé pour générer la réponse --- le mot de passe correctement chiffré.

Avec la méthode synchrone, la variable de défi utilisée pour générer le mot de passe est déterminée en interne par le jeton et le serveur. Un compteur de temps, un compteur d'événements ou une combinaison de compteur de temps et d'événements dans chaque appareil est utilisé comme base pour la variable de défi. Étant donné que le jeton et le serveur déterminent chacun séparément et en interne la variable de défi à partir de leurs propres compteurs, il est très important que leurs compteurs de temps et les compteurs d'événements restent synchronisés. Parce qu'il est si facile pour le serveur et le jeton de se désynchroniser, la plupart des implémentations permettent une certaine dérive entre les compteurs. Habituellement, une petite plage ou fenêtre de ces valeurs de compteur est utilisée pour calculer le mot de passe. Cependant, si le jeton et le serveur sont désynchronisés au-delà de cette fenêtre,

Pro:

• Les certificats ont des racines CA qui les rendent fiables et difficiles à forger
• Il existe des installations standard dans les systèmes d'exploitation pour gérer et maintenir facilement les magasins de certificats
• Approche bien étudiée, beaucoup d'informations disponibles à ce sujet
• Expiration avec une variété d'autres choses sont des installations intégrées de certificats standard, ils sont généralement robustes

Con:

• Les certificats peuvent être difficiles à utiliser par programmation
• Selon si vous avez besoin d'une autorité de certification externe, peut ne pas être gratuit
• Il peut être nécessaire de gérer manuellement les magasins de certificats pour garantir la configuration des approbations racine attendues

NTLM

Ne riez pas, s'il s'agit d'un service plus petit ou interne uniquement et que vous êtes dans un environnement Windows, il n'y a rien de mal à utiliser l'authentification NTLM standard pour garantir l'accès. Surtout si vous travaillez avec IIS, c'est de loin l'approche la plus simple. Facile à entretenir et à configurer également dans un fichier web.config.

Pro:

• Extrêmement facile à configurer, à mettre en œuvre et à entretenir

Con:

• Interopérabilité minimale
• Pas suffisant pour une authentification publique

Nonces

Lorsque vous travaillez avec des nonces dans votre approche d'authentification, vous fournissez une méthode pour obtenir un nonce sur le service. Cette méthode renvoie une chaîne ou un élément de données arbitraire unique ("un nonce") à chaque demande. Chaque demande à d'autres méthodes nécessite désormais de récupérer un nonce et de l'utiliser dans l'algorithme de chiffrement de la demande. La valeur ici est que le serveur garde une trace des nonces utilisés et ne permet jamais la réutilisation d'un nonce, cela empêche complètement les attaques de relecture car une fois qu'une demande avec un nonce est faite, une demande avec ce nonce ne peut plus être faite à nouveau. Au fur et à mesure que les nonces sont demandés, ils sont ajoutés à une liste des nonces disponibles, lorsqu'ils sont utilisés, ils sont déplacés de la liste disponible vers la liste utilisée.

Pro:

• Thwarts rejoue assez bien les attaques
• Pas tout à fait difficile à mettre en œuvre ou à comprendre

Con:

• Requiert que les clients fassent deux demandes pour chaque demande (bien que cela puisse être réduit en exigeant des nonces pour seulement certaines demandes)
• Nécessite la gestion des nonces, qui doivent être transactionnels
• Affecte négativement les performances en exigeant des demandes supplémentaires de nonces (la transactionnalité augmente encore le coût des ressources de travail avec les nonces)