Problème Connexion Client SQL
massilia68
Messages postés
7
Date d'inscription
jeudi 24 décembre 2009
Statut
Membre
Dernière intervention
15 janvier 2014
-
15 janv. 2014 à 05:31
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 - 20 janv. 2014 à 00:45
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 - 20 janv. 2014 à 00:45
A voir également:
- Mot de passe hashé et salé
- Connexion base de données - Conseils pratiques -PHP
- Commit sql ✓ - Forum SQL
- Formulaire de connexion php - Forum PHP
- Ebp probleme connexion ✓ - Forum SQL
- Decimal sql ✓ - Forum C# / .NET
6 réponses
cs_Jack
Messages postés
14006
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
79
15 janv. 2014 à 10:26
15 janv. 2014 à 10:26
Salut
Question confuse.
Ton titre parle de connexion.
Tu parles ensuite de données dans des tables.
Perso, "CMS E107", ça ne me dit rien du tout.
En fait, on n'arrive pas à savoir de quoi tu parles.
MD5 est, comme tu le dis, un chiffrage et non un cryptage.
A ma connaissance, MD5 n'est pas réversible, c'est à dire qu'on ne peut pas retrouver la donnée initiale à partir du MD5.
En général, dans les bases de données, on stocke le MD5 d'un mot de passe pour éviter de stocker des données sensibles puisque, même si un marlou mettait la main sur les valeurs de ces champs, il ne pourrait pas retrouver le MdP associé.
Simplement, lors d'une saisie de MdP, le programme doit calculer le MD5 à partir de la saisie puis le compare au MD5 stocké dans la table; S'il y a égalité, le texte (MdP) initial est bien le même.
Alors, est-ce que cela répond à ta question, je ne le sais pas, n'ayant pas compris le problème que tu rencontres.
Question confuse.
Ton titre parle de connexion.
Tu parles ensuite de données dans des tables.
Perso, "CMS E107", ça ne me dit rien du tout.
En fait, on n'arrive pas à savoir de quoi tu parles.
MD5 est, comme tu le dis, un chiffrage et non un cryptage.
A ma connaissance, MD5 n'est pas réversible, c'est à dire qu'on ne peut pas retrouver la donnée initiale à partir du MD5.
En général, dans les bases de données, on stocke le MD5 d'un mot de passe pour éviter de stocker des données sensibles puisque, même si un marlou mettait la main sur les valeurs de ces champs, il ne pourrait pas retrouver le MdP associé.
Simplement, lors d'une saisie de MdP, le programme doit calculer le MD5 à partir de la saisie puis le compare au MD5 stocké dans la table; S'il y a égalité, le texte (MdP) initial est bien le même.
Alors, est-ce que cela répond à ta question, je ne le sais pas, n'ayant pas compris le problème que tu rencontres.
cs_Robert33
Messages postés
834
Date d'inscription
samedi 15 novembre 2008
Statut
Membre
Dernière intervention
14 janvier 2017
33
19 janv. 2014 à 09:30
19 janv. 2014 à 09:30
Bonjour
Le fait que le mot de passe soit stocké chiffré dans la base me semble une bonne chose. Lors de l'identification c'est au logiciel client, ou serveur, d'appliquer l'algorithme de chiffrement avant de faire la requête sur la base.
pour être plus simple:
le client entre son identification et mot de passe en clair
To logiciel y applique l'algorithme de chiffrement utilisé lors de l'enregistrement
puis fait la requête sur la base pour l'authentification.
Le fait que le mot de passe soit stocké chiffré dans la base me semble une bonne chose. Lors de l'identification c'est au logiciel client, ou serveur, d'appliquer l'algorithme de chiffrement avant de faire la requête sur la base.
pour être plus simple:
le client entre son identification et mot de passe en clair
To logiciel y applique l'algorithme de chiffrement utilisé lors de l'enregistrement
puis fait la requête sur la base pour l'authentification.
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
211
19 janv. 2014 à 10:04
19 janv. 2014 à 10:04
Bonjour,
Autrement dit :
1) - lorsque l'utilisateur choisit (en clair) son mot de passe, on le chiffre (par un algo de chiffrement X) et le résultat est conservé en mémoire (dans une base, par exemple)
2) - lorsqu'il s'identifie : il saisit (toujours en clair) le mot de passe qu'il avait choisi. On applique à ce "clair" l'algo X du 1) et on compare le résultat de ce chiffrement avec celui enregistré en 1)
Autrement dit :
1) - lorsque l'utilisateur choisit (en clair) son mot de passe, on le chiffre (par un algo de chiffrement X) et le résultat est conservé en mémoire (dans une base, par exemple)
2) - lorsqu'il s'identifie : il saisit (toujours en clair) le mot de passe qu'il avait choisi. On applique à ce "clair" l'algo X du 1) et on compare le résultat de ce chiffrement avec celui enregistré en 1)
Bonjour, merci de vos réponse, comment dois-je faire dans ce cas la pour que mon logiciel applique l'algorithme de chiffrement lors de l'identification?
PS: Le Logiciel à été conçue en VB.NET
En vous remercient !
PS: Le Logiciel à été conçue en VB.NET
En vous remercient !
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
211
19 janv. 2014 à 21:32
19 janv. 2014 à 21:32
Ben ... Nous avions été clairs, non ?
Relis-nous donc !
Relis-nous donc !
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
J'ai bien compris, Quelle codage faut-il faire pour que mon logiciel exécute la manière de Robert33..
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
211
20 janv. 2014 à 00:45
20 janv. 2014 à 00:45
Je ne comprends pas ta difficulté.
Lorsque l'utilisateur a choisi (inscription) son mot de passe, tu l'as bien chiffré, ce mot de passe, puisque tu as écrit :
"Le soucis qui ce présente actuellement est que le mot de passe est chiffré sur la Table user_password"
et pour ce faire, tu as forcément utilisé une procédure ou un bloc d'instructions :
1) pour obtenir le résultat chiffré toto
2) pour écrire toto dans ta table
Lorsque, ultérieurement, l'utilisateur se connecte et qu'il saisit un mot de passe ===>> tu dois :
1a) lire le mot de passe chiffré dans ta table (toto, donc)
2a) appliquer au mot de passe qu'il a saisi la même procédure ou bloc d'instructions que celle citée en 1) ==>> soit titi le résultat chiffré ===>> si titi = toto, tu permets la connexion. Si non, tu la refuses.
Lorsque l'utilisateur a choisi (inscription) son mot de passe, tu l'as bien chiffré, ce mot de passe, puisque tu as écrit :
"Le soucis qui ce présente actuellement est que le mot de passe est chiffré sur la Table user_password"
et pour ce faire, tu as forcément utilisé une procédure ou un bloc d'instructions :
1) pour obtenir le résultat chiffré toto
2) pour écrire toto dans ta table
Lorsque, ultérieurement, l'utilisateur se connecte et qu'il saisit un mot de passe ===>> tu dois :
1a) lire le mot de passe chiffré dans ta table (toto, donc)
2a) appliquer au mot de passe qu'il a saisi la même procédure ou bloc d'instructions que celle citée en 1) ==>> soit titi le résultat chiffré ===>> si titi = toto, tu permets la connexion. Si non, tu la refuses.
15 janv. 2014 à 12:46
Maintenant, il est considéré que MD5 est un hashage insuffisant.
Si ton hash n'est pas salé, une simple "Rainbow table" permet de retrouver le MDP rapidement.
Maintenant, il est plutot conseillé d'utiliser SHA qui permet un hash sur plus d'octets, donc moins de collision et cela compliquerait la recherche d'une collision de hash.
19 janv. 2014 à 01:01
Auriez-vous une idée ?