Meilleures pratiques pour le stockage sécurisé des jetons d'accès
Quelles seraient les meilleures pratiques pour stocker des jetons d'accès d'une autre API pour vos utilisateurs? En particulier, je développe une application avec des amis qui permet aux utilisateurs de se connecter à Facebook pour s'authentifier auprès de notre API interne REST et la rendre capable de récupérer leurs amis (et d'autres choses).
Je pensais générer une clé et l'utiliser pour crypter le jeton d'accès à long terme du compte Facebook de l'utilisateur et éventuellement d'autres informations sensibles. Comme schéma de cryptage, j'utiliserais AES-256-CBC et la clé serait envoyée au client, qui la conserve (et la rafraîchit de temps en temps). Mais si je génère cette clé avec un caractère aléatoire, l'utilisateur ne peut utiliser qu'un seul client. Comme les autres clients auraient besoin de cette clé pour déchiffrer le jeton d'accès Facebook et d'autres données. Une solution serait de générer la clé à partir de quelque chose d'unique lors de la connexion Facebook, mais malheureusement, la seule chose que je puisse trouver est l'ID utilisateur, dont j'ai besoin pour trouver l'enregistrement de l'utilisateur dans la base de données.
Il y a en fait beaucoup de sujets à ce sujet sur stackoverflow, mais rien ne répond à ce que je veux. Ce que je veux réellement, c'est chiffrer le jeton d'accès Facebook et d'autres données à l'aide d'une clé que seul le côté client connaît. La création de ces clés ne devrait être possible que lorsque l'utilisateur s'authentifie à l'aide du sdk Facebook ou lorsque la clé actuelle est fournie.
Des idées?
La somme de ce que le client stocke et de ce que votre serveur stocke doit être suffisante pour récupérer les données secrètes spécifiques à l'utilisateur (par exemple, le jeton d'accès Facebook). Ce que le client stocke est, principalement, le mot de passe de l'utilisateur (la seule zone de stockage permanente côté client est le cerveau de l'utilisateur, si nous voulons permettre à l'utilisateur d'utiliser plusieurs machines distinctes à volonté). Si je comprends bien, vous ne voulez pas votre serveur pour stocker les données "telles quelles": dans le cas où votre serveur est complètement compromis, les secrets de l'utilisateur doivent toujours être en sécurité (autant que possible) ).
Cela indique le cryptage basé sur un mot de passe . Du mot de passe de l'utilisateur est dérivée une clé symétrique [~ # ~] k [~ # ~] qui est utilisée pour crypter symétriquement un paquet qui contient les secrets de l'utilisateur, par ex. le compte Facebook. Techniquement, cela ressemblerait à ceci:
- Lorsque l'utilisateur s'enregistre, il choisit son mot de passe [~ # ~] p [~ # ~] et l'envoie à votre serveur.
- Votre serveur génère une valeur de sel aléatoire [~ # ~] s [~ # ~] et calcule PBKDF2 sur [~ # ~] p [~ # ~] et [~ # ~] s [~ # ~], pour produire 256 bits de sortie [~ # ~] t [~ # ~ ]. Appelons [~ # ~] a [~ # ~] les 128 premiers bits de [~ # ~] t [~ # ~], et = [~ # ~] k [~ # ~] l'autre moitié de 128 bits.
- La première moitié ( [~ # ~] a [~ # ~]) est stockée dans la base de données du serveur; ce sera utilisé pour authentifier les utilisateurs.
- La seconde moitié ( [~ # ~] k [~ # ~]) est pas stockée; c'est la clé symétrique pour cet utilisateur. Les secrets de l'utilisateur seront cryptés avec [~ # ~] k [~ # ~].
- Lorsque l'utilisateur se connecte, il envoie son nom et [~ # ~] p [~ # ~] à votre serveur (via HTTPS). Votre serveur récupère le sel [~ # ~] s [~ # ~] pour cet utilisateur (tel qu'il est stocké dans sa base de données) et recalcule [~ # ~] t [~ # ~] (en utilisant [~ # ~] p [~ # ~] et [~ # ~] s [~ # ~] avec PBKDF2). Si la première moitié du recalculé [~ # ~] t [~ # ~] correspond au stock enregistré [~ # ~] a [~ # ~] , alors l'utilisateur est authentifié et la seconde moitié de [~ # ~] t [~ # ~] est [~ # ~] k [~ # ~]. Le serveur peut ensuite déchiffrer le bundle stocké et accéder au jeton d'accès Facebook.
Avec cette configuration, le serveur ne stocke (sur son disque ou dans sa base de données) le jeton d'accès Facebook en texte clair, mais il peut y accéder lorsque l'utilisateur se connecte; il appartient au serveur de se souvenir (en RAM) du jeton d'accès Facebook tant qu'il en a besoin.
Notez que lorsque l'utilisateur change son mot de passe, cela change également [~ # ~] k [~ # ~] (le serveur doit également générer un nouveau sel [~ # ~] s [~ # ~], mais même si le serveur ne le faisait pas par erreur, [~ # ~] k [~ # ~] serait toujours modifié); ainsi, le serveur doit déchiffrer le bundle stocké avec l'ancien [~ # ~] k [~ # ~] et le chiffrer à nouveau avec le nouveau [~ # ~] k [ ~ # ~] lorsque le mot de passe est modifié. Ce n'est pas difficile à intégrer car les interfaces de changement de mot de passe demandent habituellement l'ancien mot de passe et le nouveau mot de passe, donc à ce stade le serveur a les deux.
Notez également que lorsque le mot de passe est oublié, le forfait est perdu. Il n'y a pas de récupération pour ce cas. Si l'utilisateur oublie son propre mot de passe, vous devrez alors réinitialiser le mot de passe, ce qui s'apparente à une nouvelle inscription; et un nouveau jeton d'accès Facebook devra être obtenu.
Dans tout ce qui précède, nous constatons que votre serveur voit toujours le mot de passe de l'utilisateur. Si votre serveur est entièrement compromis et piraté, l'attaquant pourra observer les mots de passe des utilisateurs et les jetons d'accès Facebook des utilisateurs pour tous les utilisateurs qui se connectent pendant que l'attaquant contrôle le serveur. Empêcher ça est beaucoup plus difficile. On peut dire que si votre serveur présente uniquement une interface Web, où toute "l'intelligence" côté client est Javascript envoyée par votre serveur, alors il est impossible de faire mieux que ce que le schéma ci-dessus fait, dans cette situation.
Facebook Docs: Sécurisation des demandes d'API Graph fournit une solution simple.
J'étais à la 10ème conférence ISC de sécurité et de cryptologie la semaine dernière et là j'ai vu quelqu'un a proposé une méthode pour stocker les jetons de passe utilisateur en utilisant Neural Network . Il a créé un NN qui apprend les jetons de passe utilisateur et s'est mis à jour en utilisant une méthode d'apprentissage NN rapide. C'est une nouvelle méthode qui promet de la sécurité mais nécessite beaucoup d'attention sur l'apprentissage.
[~ # ~] mise à jour [~ # ~]
Le document était en farsi intitulé 
ça veut dire User Access Control Using Neural Network and chaotic system
(la pile ne prend pas en charge les caractères farsi! J'ai plutôt utilisé l'image !!!)