Comment implémenter la connexion automatique en toute sécurité

15

J'ai lu de très nombreux articles sur la façon dont "vous stockez probablement des mots de passe incorrects". Ils font toujours référence au stockage de mots de passe sur un serveur auquel un utilisateur se connecte; ils refont essentiellement (jeu de mots) des conseils omniprésents comme assurez-vous de saler les mots de passe, etc. etc. Cependant, je n'ai jamais vu un article sur les meilleures pratiques pour stocker les mots de passe sur un client afin que le client n'ait pas à se connecter manuellement chaque fois qu'ils veulent se connecter; la fonction "se souvenir de moi".

De nombreux logiciels ont cette fonctionnalité, des navigateurs aux programmes comme Dropbox.

J'ai lu récemment un ancien article sur la façon dont Dropbox stockait un ID sur votre ordinateur que vous pouviez simplement copier / coller sur un autre ordinateur et démarrer Dropbox et être connecté en tant que périphérique pour lequel vous avez obtenu l'ID; pas de connexion, rien, et un accès complet au compte Dropbox. Cela semble être une conception vraiment stupide, mais je ne peux pas penser à une meilleure façon de le faire.

Je ne sais même pas comment éviter de stocker quelque chose comme un cookie en texte brut. Si vous le cryptez, où stockez-vous la clé pour la décrypter?

La seule façon que je vois de ne pas introduire de vulnérabilités de sécurité consiste à supprimer la fonctionnalité de connexion automatique et à obliger l'utilisateur à taper son mot de passe chaque fois qu'il souhaite utiliser un service, mais c'est une difficulté d'utilisation et les utilisateurs sont gâtés de s'attendre à ne pas avoir à le faire.

Que puis-je lire sur le stockage local des informations d'identification en toute sécurité pour implémenter la fonction de connexion automatique? Si les principes sont trop simples pour un article entier, quels sont-ils? Le logiciel en question ne devrait pas dépendre de fonctionnalités qui ne sont pas présentes sur toutes les plateformes (comme le "trousseau" de certaines distributions Linux).

security login

— Jay Simon
source

2

Il s'agit de ce en quoi vous avez confiance. Si vous ne faites pas confiance à la machine pour stocker l'ID, c'est votre problème. Si vous faites confiance au trousseau, c'est la sécurité maximale que vous obtiendrez. Bien sûr, vous pouvez ajouter une sécurité personnalisée comme la détection du matériel de l'appareil ou quelque chose, mais tout cela est faux, donc vous ne pouvez pas le savoir à la fin. C'est hors de votre contrôle. Bien sûr, des choses stupides comme la sauvegarde de mots de passe en texte clair sont exclues.

— Luc Franken

@LucFranken comment pouvez-vous faire confiance à la machine? Quelqu'un peut vous exploiter comme il l'a fait sur Dropbox. Je ferais également confiance au trousseau, mais tous les ordinateurs n'en ont pas, et Windows ne le fait jamais (AFAIK). Et si vous stockez des mots de passe, comment éviter de les stocker en texte clair? Si vous les chiffrez, où stockez-vous la clé pour la déchiffrer?

— Jay Simon

C'est exactement le problème, vous ne pouvez pas lui faire confiance. L'utilisateur ne peut définir que pour lui faire confiance. Cela prend en compte que l'utilisateur comprend la sécurité de sa machine. Écrire un virus pour récupérer des données à partir de Dropbox est tout simplement possible. Idem avec les clés stockées localement et d'autres données locales. Vous pouvez aider à le rendre plus sûr (pensez aux applications qui nécessitent un code à 5 chiffres) mais au final, c'est local et hors de votre contrôle.

— Luc Franken

@LucFranken est-ce juste moi ou la connexion automatique semble-t-elle une fonctionnalité omniprésente? Si c'est le cas, pourquoi les gens n'ont-ils pas écrit sur la façon de bien faire?

— Jay Simon

C'est une exigence si courante bien que certains logiciels d'entreprise ne le permettent pas. Par exemple, SalesForce permet de sauvegarder uniquement le nom d'utilisateur, pas le mot de passe. Mettons clair btw. que vous n'avez pas à stocker le mot de passe chez le client pour une connexion. Vous pouvez stocker un hachage aléatoire qui correspond à un hachage sur le serveur.

— Luc Franken

12

Une façon est:

Lorsque l'utilisateur se connecte, stockez un ID de session dans un cookie sur l'ordinateur du client (pas le nom d'utilisateur ou le mot de passe).
Liez la session à l'adresse IP, donc un ID de session individuel ne fonctionne qu'avec l'ordinateur sur lequel il a été démarré.

Selon le cadre que vous utilisez pour développer votre site, ce comportement peut être disponible en tant que fonctionnalité intégrée.

Notez que, comme le protocole HTTP est de toute façon sans état, il n'y a en fait aucune différence fonctionnelle entre garder une personne connectée pendant une seule session d'utilisation du site Web et «connexion automatique» la prochaine fois qu'ils utiliseront le site; il s'agit uniquement du temps dont vous disposez avant l'expiration de la session.

Mise à jour: Utilisez également HTTPS pour une sécurité accrue, évidemment.

Mise à jour 2: Notez que cette approche a des limites, en ce qu'elle ne fonctionne pas bien pour les utilisateurs qui changent beaucoup leur adresse IP. Cependant, il offre un niveau de sécurité accru et peut être utile dans certaines situations.

1

Le lier à une adresse IP n'aide pas beaucoup car quelqu'un peut avoir un ordinateur derrière le même pare-feu que vous.

— Jay Simon

2

@JaySimon, je ne dirais pas "n'aide pas beaucoup". Le nombre d'ordinateurs derrière le même pare-feu que vous est considérablement plus petit que le nombre d'ordinateurs dans le monde. Il s'agit de limiter votre exposition potentielle aux attaques, et cela la limite considérablement. Il s'agit d'une approche standard, et je ne pense vraiment pas que vous puissiez faire beaucoup plus que cela. Si quelqu'un a la même adresse IP que l'utilisateur et parvient à obtenir un ID de session, cette personne ne pourra pas être distinguée de l'utilisateur du point de vue du serveur. Si vous avez un type de connexion sur votre site, vous êtes exposé à une telle attaque.

3

Pensez-vous qu'une telle approche sera gênante pour les utilisateurs de téléphones mobiles dont l'adresse IP peut changer souvent?

— Jay Simon

@JaySimon, si cela se produisait au cours d'une session, l'utilisateur le ressentirait comme une déconnexion soudaine, ce qui serait certainement ennuyeux. Je ne sais pas combien de fois ils changent réellement (une recherche rapide sur Google ne révèle pas de réponse définitive). Je ne serais pas trop inquiet à ce sujet à moins que l'IP ne soit susceptible de changer pendant qu'ils l'utilisaient réellement.

Restreindre la session à l'IP n'est pas vraiment réaliste comme dit. Les utilisateurs changent souvent de lieu. Avec les téléphones portables mais aussi avec les ordinateurs portables; par exemple le travail flexible. Le mieux que vous puissiez faire, c'est quelques vérifications GeoIP combinées avec le temps de parcourir cette distance; comme le fait Gmail.

— Lode

5

Amazon (et bien d'autres) utilise une approche hybride. Ils fournissent une connexion automatique pour la navigation, l'ajout d'articles au panier et la passation de commandes à l'aide de combinaisons d'adresses de crédit / de livraison que vous avez utilisées auparavant. Cependant, ils vous demandent de saisir votre mot de passe pour de nombreuses actions telles que l'ajout de cartes de crédit, l'ajout / la modification d'adresses de livraison, la mise à jour des mots de passe, la visualisation des commandes passées (facultativement pour l'utilisateur) et de nombreux autres paramètres de compte.

Alors oui, les gens qui ont accès à votre ordinateur peuvent détourner votre session, mais vous obtenez toujours ce qu'ils commandent! (Plus important encore, l'incitation à détourner une session est à peu près annulée.) Mais si quelqu'un a accès à mon ordinateur, j'ai plus de problèmes que les gens qui volent la moyenne des sessions de site.

Si certaines parties de votre application ne nécessitent pas un niveau de sécurité aussi élevé, vous pouvez choisir un modèle hybride dans lequel vous stockez un ID de session (haché ou autre si vous le souhaitez) pour connecter automatiquement les utilisateurs aux parties à faible sécurité du site. , mais les obliger à entrer le mot de passe lors de l'entrée dans les zones de sécurité supérieure et à supprimer le jeton de haute sécurité à la fin de la session.

Bien sûr, s'il s'agit d'un site de niveau bancaire, la connexion automatique n'est pas une option. Encore une fois, les sites qui utilisent ces types de sécurité supposent que la valeur des données qu'ils protègent et la commodité supplémentaire pour l'utilisateur l'emportent sur le risque potentiel d'une session piratée. Si vous pensez que ce n'est pas le cas pour votre application, n'implémentez pas les connexions automatiques. Vous devez accéder au niveau de compromis sécurité / convivialité approprié à votre cas d'utilisation.

— Eric G
source

2

Ce n'est en fait pas si difficile. Enregistrez d'abord un cookie avec ce format:

userID.token

Vous pouvez utiliser un hachage sha1 pour le jeton. Ensuite, dans votre table de base de données Remember_me_tokens, stockez l'ID utilisateur, un hachage bcrypt du jeton et l'heure de génération du jeton.

Ensuite, lorsque quelqu'un visite votre site, vérifiez si le cookie est défini. Si le cookie est défini, vérifiez s'il existe une ligne valide dans la base de données au cours des 7 derniers jours, par exemple. S'il y a une ligne valide dans la base de données pour le cookie, définissez la session pour indiquer que l'utilisateur est connecté et supprimez également la ligne de cookie / base de données correspondante et générez une nouvelle ligne de cookie / jeton / base de données.

S'ils se déconnectent, supprimez le cookie.

Exécutez une tâche cron pour élaguer Remember_me_tokens qui sont plus anciennes que disons 7 jours.

— Ryan
source

Qu'est-ce qui empêche quelqu'un de copier cette clé et de la coller sur sa machine et d'accéder au compte sans le nom d'utilisateur ou le mot de passe?

— Jay Simon

comment allez-vous obtenir la clé? il est stocké localement sur l'ordinateur de quelqu'un.

— Ryan

vous vous dirigez vers l'ordinateur et ouvrez le fichier où il est stocké :)

— Jay Simon

2

@JaySimon Ce même argument peut être fait pour quelqu'un qui se connecte et s'éloigne pendant 5 minutes sans verrouiller son ordinateur, ou clique sur Remember Me et quelqu'un saute sur le mot de passe de son compte. Si vous pouvez accepter cette situation de sécurité possible, la commodité est agréable, mais c'est pourquoi vous ne voyez pas de fonction Remember Me sur la liste CIA NOC :) Le serveur doit vous fournir une sorte de jeton que le client doit stocker sur le système de fichiers. Ce n'est plus entre vos mains du point de vue du serveur.

— maple_shaft

@maple_shaft pourquoi quelqu'un a-t-il été surpris que vous puissiez faire cela sur dropbox alors? (Je l'ai lié dans ma question.)

— Jay Simon

0

Vous ne pouvez le faire que si vous faites confiance à l'appareil sur lequel vous le stockez. Il appartient à l'utilisateur (si vous ne pouvez pas influencer l'appareil) de sa sécurité. C'est tout simplement hors de vos mains.

Comme indiqué dans les commentaires:

Il s'agit de ce en quoi vous avez confiance. Si vous ne faites pas confiance à la machine pour stocker l'ID, c'est votre problème. Si vous faites confiance au trousseau, c'est la sécurité maximale que vous obtiendrez. Bien sûr, vous pouvez ajouter une sécurité personnalisée comme la détection du matériel de l'appareil ou quelque chose, mais tout cela est faux, donc vous ne pouvez pas le savoir à la fin. C'est hors de votre contrôle.

— Luc Franken
source