HTTP Se souvenir de moi authentification

Question

J'essaye d'écrire un simple HTTP mémoriser le système d'authentification pour les utilisateurs.

Mes utilisateurs pourraient être représentés en tant que tels

{ 
"email" : "foo@bar.com", 
"password" : "8EC41F4334C1B9615F930270A4F8BBC2F5A2FCD3" // sha1 hash of password 
} 

Donc, mon idée est que je dois créer un cookie, avec le temps d'expiration indéfinie (très long), qui contiendra un certain type d'information pour me permettre de récupérer l'utilisateur à partir de la base de données, donc de se connecter à l'utilisateur.

Ma première idée était simplement de stocker la chaîne email:password en tant que cookie. Je pensais que ce serait bien puisque personne d'autre ne peut vraiment générer ce type d'information autre que l'utilisateur lui-même, et je pourrais récupérer l'utilisateur assez facilement en comparant simplement les username et password en fonction de ce qui se trouve dans la base de données.

Cependant, je pensais que ce n'était pas vraiment bon. Il convertit le résumé du mot de passe en, effectivement, un deuxième mot de passe qui est stocké en clair et passé sur le fil dans chaque demande. Alors j'ai pensé que peut-être je pourrais générer un signature chaque fois que l'utilisateur se connecte, ce qui serait essentiellement un hachage aléatoire qui est stocké directement dans l'objet utilisateur dans la base de données.

L'utilisateur se connecte, il génère cette signature qui est stockée et le cookie détient cette signature. Chaque fois que vous accédez au site Web, le site vérifie quel utilisateur possède cette signature particulière et enregistre l'utilisateur. La déconnexion effacera le cookie et les nouvelles connexions génèreront une nouvelle signature aléatoire.

Cette approche prend-elle en compte d'autres vulnérabilités?

Je sais, je devrais probablement utiliser une bibliothèque déjà faite pour cela, mais c'est simplement un exercice de sécurité web.

Answer 1

C'est essentiellement ce que font la plupart des sites lorsque vous vous connectez. Oui, le cookie doit contenir un identifiant unique pour la «session» de l'utilisateur. Le cookie devrait être essentiellement aléatoire. A vous de décider si vous voulez le rendre persistant à travers les sessions du navigateur.

Avec le cookie dans votre base de données d'authentification, stockez également un horodatage de la date de création de l'entrée. Les cookies de plus de N secondes doivent être considérés comme non valides (réglez N à votre goût). Vous pouvez réinitialiser l'horodatage chaque fois que le cookie est utilisé afin que les sessions inactives expirent. Notez que le même utilisateur peut souhaiter avoir plusieurs sessions (est-ce que vous vous connectez à votre compte e-mail depuis votre domicile ou votre lieu de travail?), Donc le concept ici est vraiment "session", pas utilisateur.

Answer 2

Les points de vue de vulnérabilité sont les mêmes! Le vol de cookies et les mécanismes associés, cependant, les navigateurs sont assez intelligents maintenant, donc vous ne devriez pas vous en préoccuper.

La deuxième approche est bonne en termes de confidentialité car elle ne comprend pas d'adresse e-mail dans le cookie. Et cela ressemble beaucoup plus au stockage de l'identificateur de session (sessionID) que dans votre cas, vous générez un hash aléatoire et le stockez dans DB. Mais je pense qu'il serait plus sage d'utiliser la première approche; vous pouvez ajouter une autre couche au résumé et le chiffrer avec votre algo ou votre clé privée; être sur un côté plus sûr.