Stockage des informations d'identification dans le stockage local
Puis-je utiliser en toute sécurité le stockage local au lieu des cookies pour stocker les informations d'identification de session?
Aurais-je besoin de stocker un hachage chiffré ??
EDIT: Serait-ce suffisamment sécurisé?
L'utilisateur se connecte.
Le serveur renvoie un message de réussite comprenant un hachage bcrypt salé mélangeant l'ID utilisateur, le mot de passe, l'horodatage et éventuellement l'adresse IP. Ceci est enregistré dans le stockage local.
Lors des futures connexions, ce hachage est envoyé, le serveur assume la responsabilité tant que l'adresse IP n'a pas changé et que le délai n'a pas expiré.
localstorage est tout aussi vulnérable à la lecture par JavaScript que les cookies.
localstorage peut être lu en utilisant JavaScript depuis le domaine même, si vous contrôlez tous les JS sur le domaine, cela ne devrait pas poser de problème. Mais si un autre code est exécuté (via l'injection par exemple, ou si vous partagez le domaine avec quelqu'un d'autre), il pourra accéder aux données de stockage.
Cependant, c'est la même chose pour les cookies, mais généralement, le cookie est défini sur HTTPOnly donc JavaScript ne peut pas le lire.
Dans les deux cas, les informations de connexion en texte brut ne doivent en aucun cas être stockées dans les cookies ou le stockage local, car si quelqu'un les obtient, il peut continuellement créer une nouvelle session pour lui-même.
Vous devez crypter un identifiant authentifié (tel que leur ID utilisateur) avec l'heure de la date d'expiration de la session, puis stocker cette valeur dans un cookie ou un stockage local. Ce jeton est ensuite validé à chaque appel serveur.
Si vous allez utiliser le stockage local, pourquoi stocker les informations d'identification des utilisateurs ou tout ce qui en dérive?
Ce que j'ai cherché à faire, c'est:
Une fois la connexion réussie, générez une chaîne complètement aléatoire sans rapport avec les informations d'identification de l'utilisateur et stockez-la dans la base de données, avec une date d'expiration. Je passerais ensuite cette chaîne à mes js pour qu'elle soit stockée dans le stockage local.
À partir de là, tant que ces informations d'identification de stockage local correspondent à celles de la base de données et que le délai d'expiration n'a pas expiré, je les considère automatiquement comme étant connecté.
De cette façon, il n'y a aucun risque concernant l'exposition des informations d'identification de l'utilisateur à partir du stockage local. Cependant, avec cette chaîne unique temporaire fonctionnant essentiellement comme un identifiant de session, vous devrez toujours être conscient et prendre des précautions contre les risques associés au détournement de session.
Dans tous les cas, je crois comprendre que le stockage local est aussi sécurisé que le serveur derrière votre site. J'entends par là que le stockage local n'est accessible que via des scripts provenant de votre propre domaine, vous êtes donc en sécurité tant que le seul code frontal en cours d'exécution est le vôtre.
Votre serveur doit générer un morceau de données unique (pour le serveur) qui ne peut pas être utilisé pour découvrir le nom d'utilisateur/mot de passe. Seul ce jeton peut être stocké sur la machine de l'utilisateur sous quelque forme que ce soit. Ni localStorage ni cookie ne sont sécurisés. Les mêmes règles leur étaient donc applicables à cet égard.
Vous devez disposer de certains moyens pour expirer ce jeton, sinon une fois volé, ce jeton peut être utilisé à la place de véritables informations d'identification.
Si vous allez utiliser localStorage au lieu des cookies, vous pouvez rendre les choses plus sécurisées que les cookies. En effet, vous n'avez pas besoin d'envoyer un identifiant de session au serveur avec chaque demande, ce qui en fait un jeton de support. Au lieu de cela, vous pouvez stocker un secret utilisateur côté client dans localStorage et l'utiliser pour signer vos demandes en plus de la clé publique correspondante envoyée et utilisée comme identifiant de session. De cette façon, personne côté serveur ou proxy ne peut simuler vos demandes.