SECURITE ANTI PIRATAGE ENVOI DE MOT DE PASSE CRYPTE SANS SSL
cs_Nebraska
Messages postés
13
Date d'inscription
jeudi 10 juin 2004
Statut
Membre
Dernière intervention
13 octobre 2004
-
14 juin 2004 à 10:50
kertimanoff Messages postés 75 Date d'inscription samedi 3 décembre 2005 Statut Membre Dernière intervention 30 juin 2013 - 20 août 2010 à 16:58
kertimanoff Messages postés 75 Date d'inscription samedi 3 décembre 2005 Statut Membre Dernière intervention 30 juin 2013 - 20 août 2010 à 16:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/23446-securite-anti-piratage-envoi-de-mot-de-passe-crypte-sans-ssl
https://codes-sources.commentcamarche.net/source/23446-securite-anti-piratage-envoi-de-mot-de-passe-crypte-sans-ssl
20 août 2010 à 16:58
et en suite il n'aura qu'a entré le hash dans le champs password et ça marchera parfaitement.
disont que t'a source est un premier filtre pour les pirate du dimanche, mais c'est quand même tout a fait vulnérable.
25 juin 2007 à 00:28
pour l'unicité de l'utilisation du préfixe, l suffit de le stocker dans le profil de l'utilisateur et de vérifier à la connexion suivante que le préfixe est différent.
Ce qui me pose davantage problème, c'est que, sauf erreur de ma part, ce système ne permet pas aux utlisateurs de choisir eux mêmes et de modifier leur mot de passe puisqu'il n'est pas décodé avant stockage.
Le système de hashage n'est pas adpaté dès lors qu'on offre ce genre de fonctionnalités ?
11 juin 2007 à 10:50
11 juin 2007 à 10:45
Le préfixe ne dépend pas de la date.
Le code doit être amélioré sur 2 points.
1 / l'interdiction d'utiliser 2 fois le même préfixe.
2 / il n y a pas de précision sur les numéros de sessions, une fois identifié il faut regenerer un nouveau id de session (session_regenerate() il me semble. Ceci afin d'éviter que le pseudo hacker utilise le numero de session qui a servi a l'authentification.
9 juin 2007 à 09:21
bonne idée que cette histoire de préfixe, en améliorant un chouilla ton script on doit pouvoir sécuriser correctement l'identification
puisque le préfixe dépend de la date, si par exemple on prends comme précision la minute, ça ne laisse qu'une minute au hackeur pour sévir
si en plus de ça on mémorise les préfixes utilisé, pendant par exemple plus d'une minute, le hackeur ne pourra pas se logger
mais il faut alors que le préfixe dépende aussi du login, sinon personne ne peut se logger pendant une minute...
de plus apparemment dans ton script au dessus les identifiants sont stockés en clair, le mieux est donc un double cryptage : stockage en crypté, ajout d'un préfixe à cet id crypté puis cryptage de l'ensemble
coté client c'est pareil on crypte une fois, on ajoute le préfixe et on recrypte avant d'envoyer
vous en pensez quoi ?
3 mai 2006 à 15:56
il faut faire un controle sur le prefixe, genre interdiction d'utiliser le meme prefixe une fois que l'authenfication a réussi.
2 mai 2006 à 16:21
21 mai 2005 à 09:46
<script src="md5.js"></script>
<form method="post" action="page.php" name="requester" ENCTYPE="multipart/form-data">
Pseudo:
PWD:
</form>
Sauf que si l'utilisateur dit "NON" à l'alerte que le navigateur affiche, alors l'utilisateur devra retaper son mot de passe. Mais on peut alors rajouter un code JS qui fait afficher un message en rouge.
21 mai 2005 à 00:05
9 avril 2005 à 12:06
23 févr. 2005 à 14:17
Ce n'est pas $_GET("login") mais $_GET[ 'login' ] ;)
A+
23 févr. 2005 à 12:40
Néanmoins, j'ai une remarque à faire pour ceux qui désirent se baser sur ce tuto : si vous n'avez pas configuré votre PHP pour accepter les variables globales, ce code ne fonctionnera pas. Mais il suffit alors de remplacer les $login par $_GET("login"), etc ;-)
Merci encore à kalachnikov :-)
8 juil. 2004 à 23:16
Je pourrais avoir ton aide stp ?
Je suis dispo sur MSN :
KevinChalet@hotmail.com
Merci
A+
17 juin 2004 à 14:11
d ailleurs je pense que c est meme mieux
comme ca il n y a qu un seul paquet reso qui contient ce timecode.
Sinon merci pour celui qui a mis 10/10 :)
17 juin 2004 à 01:22
D'ailleurs, je me suis inspiré du principe pour faire la gestion de la partie admin d'un site, sauf que pour moi le serveur n'envoie pas de timecode, c'est le javascript qui se contente de rajouter la date du jour avant de passer au md5, et php de son coté fait pareil : date+pass dans le md5 et compare, le système marche nickel :p
Merci pour cette source finalement très intéressante a mon avis :)
16 juin 2004 à 22:41
qu un algo de hachage merdique :)
(j ai volontairement fait un truc concis pour
mettre le code source sur la page web,
que ce soit pas trop long a lire,
et pour mettre en evidence qu il faut la meme fonction de hachage côté clien et serveur).
m2k j ai pas passé assez de temps dessus,
je pense qu il me faudrait un mois pour qu il soit aussi bien que md5.
pour ceux qui veulent un md5 en javascript :
http://developpeur.journaldunet.com/tutoriel/sec/010828sec_cryptohachage.shtml
en fait je croyais que c etait long,
mais jpense qu en virant les commentaires, ca le fait.
j ai pas testé, faudrait voir si ca donne les memes resultats côté serveur,
car pour php y a juste a taper md5("tachaine'); ...
au pire si c est pas le meme,
faut juste faire un portage des lignes en javascript en php.
15 juin 2004 à 18:30
bon, dsl, mais n'importe quoi... je dit n'importe quoi :p
j'ai relu plus attentivement et c'est vrai que nul part le hash n'est 'déhashé' (je connait pas le voca dsl); quand j'ai lu le code vite fait je croyais que tu décodais le pass reçu par le serveur pour le comparer avec la bdd mais non, en fait ça code le pass contenu dans la bdd selon le timecode utilisé pour coder le pass envoyé par l'utilisateur.... aaaaaah ok :)
Bon, je change de commentaire alors :
L'idée d'envoyer un timecode pour l'ajouter au codage des données est intéressante, et mème si ton algo n'est pas aussi performant qu'un md5 comme tu dit, c'est une très bonne base pour sécurisé un site (a propos : md5 inclus dans php et sur le site javascript de codes-sources en cherchant un peu j'ai trouvé une implémentation de md5 pour javascript, y'a surement moyen de s'en servir mais comme a mon habitude j'ai pas testé, je sais pas a quelle vitesse elle tourne :p)
15 juin 2004 à 13:36
ca marche que dans un sens,
le hachage permet de générer une clé de longueur fixe à partir d une chaine de longueur variable.
donc impossible de retrouver quoique ce soit avec un haché,
le seul moyen est le brute force.
voici quelques exemples de ce que m2k donne :
\0(caractère nul)-> 84ee50c22c06951d43a90f6df13579b0
h -> 9af8a3d7856bff771c0e689abcdef062
i -> 29cf93af8f7ed0c22c06789ab4a1076d
j -> 183a4f5b154733bb3a2406907e5c3648
k -> 01e39f03a3bcd2e8ca24b2907a01ab45
kk -> 9a6a582e033bd047e87a1c368ace2056
kkk -> c4ad007c4a99ac541cccba994ff496be
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk -> 7961c27716b886cb306f2de9e917eb81
kkkkkkkkkkkkkkkkkklkkkkkkkkkkkkkkkkkkkk -> a3114ca54a7cf813360be9337bdde549
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK -> 1aff80eb6a0318ec0d4580ddfa974019
lllllllllllllllllllllllllllllllllllllll -> a0fdb09662d5b8e8302c7dee4be72f76
sain -> 92d9192dfec47e0b148aa6b4ebedd9df
sein -> d2d1d925f68cb68f904e6a78e76dd55b
sain dans une chaine un peu plus longue -> 3dbdb5231765f46c0cd7086534659a04
sein dans une chaine un peu plus longue -> 77b9b5641f2d34ee689bcc2930e99680
dans tous les cas c est loin de valoir un md5,
d une part mon algo est 32 fois plus lent.
d autres part le but d un haché est que la clé subisse une extreme variation meme si on change qu un seul caractère dans une chaine très longue.
Or on commence a voir des collisions sur les 2 derniers exemples.
Mon code a juste l avantage d etre concis.
15 juin 2004 à 11:57
Ici, si un hacker potentiel s'amuse a récupérer la page qui arrive et les données renvoyées ensuite, il peut décoder le pass renvoyé il me semble
15 juin 2004 à 10:14
login : perso
prenons un gars qui a un mot de passe : toto
le serveur lui envoie le prefixe (nombres de seecondes depuis 1/1/1970) : 1087294154
tu fais le hachage côté client.
m2k(prefixe+passe) - > m2k("1087294154toto") -> 061041eb1b23a366fd0cc33540813f16
le serveur recoit
login : perso
prefix : 1087294154
haché : 061041eb1b23a366fd0cc33540813f16
le serveur fait un requete genre sélectionne moi le mot de passe de perso.
donc il trouve toto(dans la base, donc tout se passe côté serveur, il n y a pas de transfert du mot de passe en clair).
le serveur fait la meme chose que le client, c est a dire il va haché le prefix et le passe.
m2k(prefixe+passe) - > m2k("1087294154toto") -> 061041eb1b23a366fd0cc33540813f16
si les 2 hachés correspondent, alors le loging est bon sinon c est que c est pas le bon passe.
14 juin 2004 à 18:40
si tu met php, ce sera du code interprété coté serveur, donc tu ne pourras pas l'utiliser coté client, et donc pas encoder ton texte.
J'ai pas tout lu(la flemme, sans doute) mais il me semble que dans le code php(coté serveur) on peut décoder le texte assez simplement, donc ça doit ètre un algo symétrique; l'idéal serait avec cette méthode d'utiliser un algorithme assymétrique qui ne fait que coder les données : coté client on encode, et coté serveur on stocke la chaine codé, et on ne compare que les chaines codé.
La difficulté vient que trouver un algorithme assymétrique est assez cho quand mème
14 juin 2004 à 18:16
14 juin 2004 à 10:50