Discussion :

[Invité]

bonjour,

en expliquant à une personne , que dans la base de données je cryptais son mot de passe, il m'a demandé pourquoi je ne cryptais pas également son login.
j'ai pas sûr quoi répondre sur le coup, mais même après réflexion, je ne trouve pas de réponse.
si on crypte le login et le mdp c'est doublement mieux non? au pire, ça diminue par 2 le risque ou le temps de hack.

alors pourquoi, on ne le fait pas ? j'ai regardé plusieurs tuto et aucun ne dit de le faire, à chaque fois c'est que le mdp.
Techniquement, ça ne pose aucun souci en programmation. En plus l'avantage c'est que ça réduit le piratage "humain" et ça améliore le respect RGPD (si quelqu'un récupère un listing des logins ou étudie les logs).

y-a-t-il une réponse évidente à pourquoi on ne crypte pas aussi le login dans la base de données ?

[A3gisS3c]

Hello,

Hasher, pas crypter.

Première raison
Déjà que les mots de passe ont une entropie à ch...(= mot de passe de style Azerty123!), tu ne fais que décaler le problème et accessoirement emmerder un peu plus l'utilisateur lambda.
Passe à du MFA autre que mot de passe si tu veux améliorer la sécurité. Sans compter qu'avec deux secrets, l'utilisateur va juste rajouter une lettre sur son deuxième mot de passe, ta sécurité n'est pas améliorée.

Deuxième raison
D'autre part, etc'est la raison la plus importante, tu fais comment pour retrouver l'utilisateur? Normalement la BDD retrouve le login, et teste le hash de ton mot de passe avec le hash contenu dans sa base.

Avec un utilisateur hashé, il va falloir qu'il check chaque utilisateur pour voir si le hash correspond... Sur une base d'1 million d'entrées ton login va te prendre 2 heures oublie direct.

[unanonyme]

Bonjour,

c'est plus pratique de garder le login en clair
dans l'hypothétique et très éventuelle situation
où l'on souhaite l'afficher dans l'IHM.

1 million de lignes ça ne pose pas de souci
à un serveur de bases de données correctement administré,
avec un schéma correctement conçu, sur une configuration
correctement dimensionnée.

Autrement, oui, on utilise une fonction de hachage,
tels que argon2 ou scrypt pour leurs propriétés spécifique de résistance.
Plutôt qu'une fonction de chiffrement comme aes, pgp ou rsa, par exemple.

Par définition, un message chiffré (crypté) doit pouvoir être déchiffré,
alors qu'un message haché fait correspondre un espace d'adressage avec une valeur,
de manière difficilement réversible mais facilement recalculable.
Ce sont ces dernières propriétés qui nous intéressent.
On oubliera pas de proprement salé son hasheur.

Pour MFA et l'entropie je sais pas, j'imagine qu'ils font une partouze
dans l'arrière cours des hackeurs vu le nombre de piratage en augmentation constante.
Ou ce n'est peut être qu'un sentiment d'insécurité numérique, ou les anglais

Bonne journée.

[Invité]

Hello,

Hasher, pas crypter.

Première raison
Déjà que les mots de passe ont une entropie à ch...(= mot de passe de style Azerty123!), tu ne fais que décaler le problème et accessoirement emmerder un peu plus l'utilisateur lambda.
Passe à du MFA autre que mot de passe si tu veux améliorer la sécurité. Sans compter qu'avec deux secrets, l'utilisateur va juste rajouter une lettre sur son deuxième mot de passe, ta sécurité n'est pas améliorée.

Deuxième raison
D'autre part, etc'est la raison la plus importante, tu fais comment pour retrouver l'utilisateur? Normalement la BDD retrouve le login, et teste le hash de ton mot de passe avec le hash contenu dans sa base.

Avec un utilisateur hashé, il va falloir qu'il check chaque utilisateur pour voir si le hash correspond... Sur une base d'1 million d'entrées ton login va te prendre 2 heures oublie direct.

je ne comprends pas ces raisons
si dans mon système, ma table des utilisateurs par exemple, j'ai ça :

nom complet : string
login : md5 string
mdp : md5 string

L'utilisateur peut continuer à saisir son login en clair et son mdp (sauf si j'utilise le masque *** côté IHM)
et côté serveur, la test se fait simplement par :
md5(saison mdp)=md5(mdp) AND md5(saisie login)=md5(login_bdd)

En effet, la seule personne que ça embêtera , ce sera l'admin si il a besoin de faire une recherche, mais à lui, on lui communiquera le nom complet.

ps : la sécurité à 2facteurs (mfa) , j'aime bien pour les applications pro ou très privé mais je suis contre pour les applications e-commerces car ça donne au marchants un 2eme moyen de vous envoyez des pubs ou de vendre vos coordonnées, donc les authentification par sms, je les refuse systématiquement pour le e-commerce.

[A3gisS3c]

c'est plus pratique de garder le login en clair
dans l'hypothétique et très éventuelle situation
où l'on souhaite l'afficher dans l'IHM.

Oui en plus! comment j'ai pu oublier cette evidence.

Pour MFA et l'entropie je sais pas, j'imagine qu'ils font une partouze
dans l'arrière cours des hackeurs vu le nombre de piratage en augmentation constante.

Oui les MST ca doit y aller je confirme :p mais quand je vois la sécurité desastreuse de 90% des boites en france bon...



@clavier12azqswx
Si ton login est en clair dans la BDD, pourquoi garder son hash dans cas ca n'a pas de sens.

[sambia39]

Bonjour,


à mon avis, il y a plusieurs raisons pour lesquelles c'est justifié et d'autres pour lesquelles ça ne l'est pas.
Le chiffrement des mots de passe est justifié car il permet d'éviter qu'ils soient lus directement en cas de fuite de la base de données. Cependant, le plus souvent, le login ou l'identifiant n'est pas vraiment considéré comme une donnée confidentielle, et peut donc être considéré comme une donnée d'identification publique. Ainsi, contrairement au mot de passe dans le contexte que je décris, le login ne nécessite pas nécessairement ou normalement un haut degré de confidentialité, mais il est important de préserver son intégrité, éventuellement au moyen d'une fonction de hachage qui est utilisée pour vérifier l'intégrité de ces données en clair, soit pour détecter qu'elles n'ont pas été altérées, même si leur contenu n'est pas dissimulé ou pour empêcher leur modification non autorisée. C'est pourquoi les bonnes pratiques recommandent l'authentification sécurisée plutôt que le chiffrement de l'identifiant ou du login. Le login peut donc êtres caractérisé comme une donnée d'authentification publique, dont l'intégrité et la disponibilité doivent être préservées, mais sans exigence ultime ou absolue de confidentialité de son contenu textuel ou de son contexte d'utilisation. (Par contexte d'utilisation, j'entends le lieu, la responsabilité, etc.)

D'autre part, chiffrer le login ou identifiant compliquerait certaines fonctionnalités comme la récupération de mot de passe par email. Il faudrait trouver une méthode pour identifier l'utilisateur sans son login en clair ; or, lors de l'authentification, le système doit pouvoir être en mesure de vérifier rapidement que le login ou identifiant correspond avant même de chiffrer le mot de passe saisi. Un login ou identifiant chiffré alourdirait cette étape. Son principal enjeu réside ou converge, à mon sens, toujours dans le contrôle d'accès lors de sa saisie et de son traitement côté serveur, afin d'éviter les usurpations ou les modifications abusives. Un chiffrement total n'apporterait à cet égard aucune protection supplémentaire mais bien au contraire une protection très limitée. Aussi, contrairement à un mot de passe, le login n'est en principe pas réutilisé sur plusieurs sites. Il est donc moins sensible à une fuite unique. Et n'oubliez pas que chiffrer n'empêcherait pas les attaques par dictionnaire.

Il est préférable et important de préciser le périmètre technique concerné, comme le web, le mobile ou les systèmes critiques, plutôt que de parler du chiffrement de l'identifiant ou du login, sans oublier que les enjeux diffèrent selon les contextes. Ainsi, parlons davantage des risques liés que de la "confidentialité des logins ou identifiants". Il me semble plus pertinent de raisonner en termes de "risques liés". En des termes plus clairs, pour quelles menaces le chiffrement des logins ou identifiants apporte-t-il une réponse appropriée ?


à bientôt

[Escapetiger]

(.../...)
Autrement, oui, on utilise une fonction de hachage,
tels que argon2 ou scrypt pour leurs propriétés spécifique de résistance.
Plutôt qu'une fonction de chiffrement comme aes, pgp ou rsa, par exemple.

Par définition, un message chiffré (crypté) doit pouvoir être déchiffré,
alors qu'un message haché fait correspondre un espace d'adressage avec une valeur,
de manière difficilement réversible mais facilement recalculable.
Ce sont ces dernières propriétés qui nous intéressent.
On oubliera pas de proprement salé son hasheur.
(.../...)

, Wikipedia:

Fonction de hachage

« Les fonctions de hachage sont liées (et souvent confondues avec) les sommes de contrôle, les clés de contrôle, les empreintes numériques, la compression avec perte, les générateurs de nombres aléatoires, les codes correcteur et les chiffrements. Bien que les concepts se chevauchent dans une certaine mesure, chacun a ses propres utilisations et exigences et est conçu et optimisé différemment. La fonction de hachage diffère de ces concepts principalement en termes d'intégrité (cryptographie). »

&

Salage (cryptographie)

« Le salage est une méthode permettant de renforcer la sécurité des informations qui sont destinées à être hachées (par exemple des mots de passe) en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques ne conduisent à la même empreinte (la résultante d’une fonction de hachage). Le but du salage est de lutter contre les attaques par analyse fréquentielle, les attaques utilisant des rainbow tables, les attaques par dictionnaire et les attaques par force brute. Pour ces deux dernières attaques, le salage est efficace quand le sel utilisé n’est pas connu de l’attaquant ou lorsque l’attaque vise un nombre important de données hachées toutes salées différemment.

Rappels sur la problématique de la gestion des mots de passe (.../...) »