SECURISATION D'UNE ZONE
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
-
11 nov. 2008 à 14:13
nicomilville Messages postés 3472 Date d'inscription lundi 16 juillet 2007 Statut Membre Dernière intervention 28 février 2014 - 11 nov. 2008 à 19:06
nicomilville Messages postés 3472 Date d'inscription lundi 16 juillet 2007 Statut Membre Dernière intervention 28 février 2014 - 11 nov. 2008 à 19:06
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/48422-securisation-d-une-zone
https://codes-sources.commentcamarche.net/source/48422-securisation-d-une-zone
11 nov. 2008 à 19:06
a++
PS : cette source existe déja de niveau plus ou moins haut et en version objet, ton code n'a pas sa place ici pour l'instant et encore moins en niveau initié.
11 nov. 2008 à 18:57
11 nov. 2008 à 18:48
Déjà ta table SQL n'est pas optimisée. Pourquoi mettre un identifiant de 15 caractères alors que dans la réalité 5 ou 6 devrait largement suffire. Pareil pour les autres champs. Je n'ai jamais vu de password de 100 caractères. Tu parles en plus de stocker le password en md5 dans la base. Sachant qu'un md5 a toujours une longueur de 32 caractères, pourquoi laisses-tu une place de 100 caractères ? Le login est aussi un champ unique théoriquement. Pourquoi n'y a-t-il pas d'index d'unicité sur le login et un index simple sur le password ?
Concernant la sécurité md5, celle que tu as mise en place n'est pas suffisante car il existe des tableaux de correspondance password clair / password hashé qui te permettent de retrouver un password en clair depuis son équivalent hashé. Pour éviter cela, il faudrait faire entrer en jeu une salt (ou graine) en plus à ton password.
En ce qui concerne ton code PHP, il n'a rien de securisé puisque :
1/ Tu passes ton login et ton password dans l'url. On ne passe pas de password dans l'url même crypté, c'est déjà une première mauvaise pratique.
2/ Tu mélanges logique métier et affichage. En gros ça devient vite le foutoir et en l'état ton code n'est presque pas réutilisable ailleurs.
3/ Que se passe-t-il si la requête SQL échoue ? Ton code continue de tourner alors qu'il ne devrait pas et il risque d'afficher plein d'erreurs PHP qui donnent plein d'informations à un pirate. Encore là, la sécurité est assez médiocre.
4/ Pourquoi utiliser des fonctions obsolètes PHP 4 comme mysql_*() alors que l'extension PDO ou MySQLi existent en PHP 5 ?
5/ mysql_fetch_array() est lent. Préfère mysql_fetch_assoc()
6/ Pas de SELECT * mais on liste les champs
7/ Pourquoi tu boucles sur tous les champs pour tester les logins et passwords alors que tu peux tout faire en une requête SQL ?
bref y'a plein de trucs qui ne vont pas. Ton code doit directement aller à la poubelle. Il est d'une part faux et d'autre part complètement obsolète.
++
PS : ne prends pas mal mes remarques malgré tout.
11 nov. 2008 à 17:41
Dit le si tu crois que je vais trop loin mais je ne crois pas que cette source soit de niveau initié non plus mais plutot de niveau débutant, il n'y a rien de formidable a mettre un champ text et un bouton dans une page et a récupèrer le text pour le crypter en md5 et l'envoyer a un autre fichier qui l'enregistre dans une base mysql.
Peus tu m'expliquer plus en détail ce que ta source nous apporte ?
a++
11 nov. 2008 à 14:13
en quoi ca vaut expert ?
# $retour = mysql_query('SELECT * FROM login ORDER BY id DESC');
pourquoi selectionner plein de lignes ? et pourquoi les trier ?
alors que tu peux te contenter de faire un SELECT 1 FROM login WHERE login="monlogin" AND password="monmd5"
ca serait beaucoup plus rapide...