Utiliser HMAC-SHA1 pour l'authentification API - comment stocker le mot de passe client en toute sécurité?
dans une API RESTful qui utilise S3-style authentification, le client API signe la demande avec sa clé secrète en utilisant HMAC-SHA1, de sorte que la clé secrète n'est jamais transmise par fil. Le serveur authentifie alors le client en utilisant la clé secrète de ce client pour répéter le processus de signature lui-même et comparer le résultat à la signature transmise par le client.
tout cela est beau et bon mais cela signifie que le serveur a besoin d'accéder au texte en clair de la le secret partagé du client. Cela va à l'encontre de tous les conseils là-bas contre stocker les mots de passe de l'utilisateur dans le clair à l'intérieur de votre base de données. Stocker seulement le hash salé du mot de passe n'est pas une option pour autant que je puisse dire - parce que je ne peux pas vérifier la signature du client.
je dois souligner que mon API est RESTful et donc devrait être stateless: je préfère éviter une étape de connexion avant les autres appels API.
une solution optionnelle est de crypter tous les mots de passe utilisateurs en utilisant un algorithme de clé symétrique. Cependant, le serveur devrait stocker la clé de cryptage quelque part facilement accessible, p.ex. à l'intérieur du code source. C'est mieux que rien mais pas une solution optimale (comme @Rook l'a mentionné dans sa réponse, cela viole le CWE-257).
une autre direction pour une solution pourrait être quelque chose autour des signatures asymétriques, mais je ne peux pas comprendre comment appliquer cela au HMAC, et ne peux pas trouver d'articles sur le sujet.
est-ce que je manque quelque chose d'évident ici? De nombreux fournisseurs respectables ont mis en œuvre ce genre de schéma d'authentification - ils ne peuvent pas tous violer les principes de sécurité communs, n'est-ce pas? Si non, existe-il des meilleures pratiques que vous pouvez partager?
3 réponses
C'est l'inconvénient de l'authentification symétrique-clé challenge-style de réponse - vous ne mettez pas le secret sur le fil, mais vous devez stocker le secret aux deux extrémités. (Les HMAC sont des systèmes de clés symétriques).
Notez bien que ce n'est pas un mot de passe - secret partagé. Il y a une différence fondamentale ici - un mot de passe est généralement choisi par l'utilisateur, alors qu'un secret partagé est généré au hasard et fourni à l'utilisateur (ils sont souvent appelés "API keys", dans ce contexte).
stocker les mots de passe dans un format réversible est mauvais, parce que si votre base de données est compromise, alors les attaquants ont obtenu des mots de passe qui pourraient (et probablement ont été) utilisés ailleurs. Stocker un secret partagé, d'un autre côté, n'est pas un tel problème - le secret est spécifique à votre service, donc tout ce que les attaquants ont acquis est la capacité de se connecter à votre service.
d'un autre côté, il possible d'avoir un système asymétrique qui n'a pas besoin de stocker un secret du côté du serveur. L'idée de base est que le serveur connaît la clé publique du client et le numéro de séquence de message courant. Lors de l'envoi d'une requête API, le client incrémente le numéro de séquence du message et calcule une signature sur le numéro de séquence et les paramètres de requête API, que le serveur peut vérifier à l'aide de la clé publique. Le serveur rejette un message s'il contient un ancien numéro de séquence de message, afin d'empêcher la rediffusion attaques.
idéalement après l'ouverture de session de l'utilisateur, vous leur donnez une Nonce cryptographique qui est utilisée comme clé secrète HMAC K pour la durée de cette session. C'est une approche sûre, mais pas reposante, parce que le repos est apatride. Cette idée d'un code d'authentification de message émis par le login est techniquement une forme d'état.
crypter les mots de passe et les stocker dans la base de données est une violation de CWE-257.
Je ne suis pas sûr que je manque quelque chose ici mais une option est d'utiliser le mot de passe hashé comme clé symétrique.