SECURITE ANTI PIRATAGE ENVOI DE MOT DE PASSE CRYPTE SANS SSL

Messages postés
13
Date d'inscription
jeudi 10 juin 2004
Statut
Membre
Dernière intervention
13 octobre 2004
- - Dernière réponse : 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

kertimanoff
Messages postés
75
Date d'inscription
samedi 3 décembre 2005
Statut
Membre
Dernière intervention
30 juin 2013
-
c'est une solution d'utiliser js pour hacher le passwd coté client afin qu'il ne transite pas clairement sur le réseau, mais un pirate aguéri enregistrera ta page de connexion sur son pc, modifira le JS pour qu'il ne hach rien du tout, il mettra l'url compléte de la page a poster dans l'action du formulaire.
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.
stephswin
Messages postés
2
Date d'inscription
lundi 25 juin 2007
Statut
Membre
Dernière intervention
26 juin 2007
-
Bonsoir,

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 ?
cs_kalachnikov
Messages postés
16
Date d'inscription
samedi 5 juin 2004
Statut
Membre
Dernière intervention
23 juin 2004
-
3 ème point / concernant le stockage en clair, il faudrait également penser a vider les champs f_login et f_password avant la soumission du formulaire (en jscript genre document.getElementById('f_password').value = '';)
cs_kalachnikov
Messages postés
16
Date d'inscription
samedi 5 juin 2004
Statut
Membre
Dernière intervention
23 juin 2004
-
Le timestamp servant a générer le préfixe n'est qu'un exemple de génération aléatoire.
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.
endlersman
Messages postés
1
Date d'inscription
samedi 26 mai 2007
Statut
Membre
Dernière intervention
9 juin 2007
-
bonjour

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 ?