CREATION DE COMPTE AVEC CRYPTAGE ET ESPACE DE CONNEXION SECURISÉ
bm1982
Messages postés
58
Date d'inscription
mardi 8 janvier 2008
Statut
Membre
Dernière intervention
10 juin 2012
-
2 juil. 2011 à 17:02
Sawadougou Messages postés 1 Date d'inscription jeudi 8 septembre 2011 Statut Membre Dernière intervention 9 septembre 2011 - 9 sept. 2011 à 15:31
Sawadougou Messages postés 1 Date d'inscription jeudi 8 septembre 2011 Statut Membre Dernière intervention 9 septembre 2011 - 9 sept. 2011 à 15:31
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/53343-creation-de-compte-avec-cryptage-et-espace-de-connexion-securise
https://codes-sources.commentcamarche.net/source/53343-creation-de-compte-avec-cryptage-et-espace-de-connexion-securise
9 sept. 2011 à 15:31
24 juil. 2011 à 22:41
http://imageshack.us/photo/my-images/221/erreurgj.jpg/
http://imageshack.us/photo/my-images/845/erreur2.jpg/
http://imageshack.us/photo/my-images/684/erreur3m.jpg/
p.s: Je suis debutant dans la programation
23 juil. 2011 à 11:37
23 juil. 2011 à 10:22
22 juil. 2011 à 21:58
22 juil. 2011 à 19:26
@kohntark : "Que tu fasses n'importe quoi côté client les données seront toujours accessibles en clair pour un "man in the middle", non ?". Celui qui veut intercepter les données pourra intercepter le challenge lors du chargement de la page et le userId + un hash d'une chaine à moitié inconnue. Le challenge doit être calculé à partir de pseudo-aléatoire et aussi des données fournies par le client (ip, navigateur) car sinon, tu as raison : n'importe qui peut utiliser le hash posté. C'est vrai que j'avais oublié d'en parler ...
22 juil. 2011 à 18:46
Oui, renseigne toi sur le brute force HackMD5, y a assez d'exemple sur le site même ou ailleurs...
18 juil. 2011 à 14:37
Désolé de relancer le truc mais je n'ai pas tout compris, même si j'ai une petite idée.
@ghuysmans99 :
Que tu fasses n'importe quoi côté client les données seront toujours accessibles en clair pour un "man in the middle", non ?
Si tu transformes côté client 'monmotdepasse' en une string 'jdfn87à"r@]'"r\çdscuids++O°+ç' à coup de md5(), SHA, salt and Co rien n'empêchera de récupérer cette string.
Si on re poste ensuite 'jdfn87à"r@]'"r\çdscuids++O°+ç' vers le serveur qu'est ce qui fait qu'il ne l’acceptera pas ("Rien à vérifier côté serveur") ?
Cordialement,
Kohntark-
9 juil. 2011 à 14:58
9 juil. 2011 à 14:54
Je vais travailler cela. Pour bien sur, sécuriser le client.
Merci pour cette info qui m'a échappée.
4 juil. 2011 à 22:42
4 juil. 2011 à 22:03
Et c'est bien ce que je pensais. Tu hash en js. Mais le problème pour moi, c'est la sécurité.
Et donc pour moi c'est pareil que de ne rien hasher car, le js peut être supprimé avant l'envoi par un hacker.
De plus, il faut vérifier ci le code à bien été hasher après l'envoi. Donc, complexe pour rien.
Tu vois ce que je veux dire ?
4 juil. 2011 à 19:28
4 juil. 2011 à 19:26
@Stay : pour hasher des données avant l'envoi, il suffit de lancer une fonction JS dans l'événement onSubmit du formulaire et de modifier (ici) le champ password : f.password=md5(md5(f.password)+f.challenge); [petite répét' d'un post précédent] Je sais bien que le MD5 d'un MD5 c'est pas top mais je ne stocke pas les mdp en clair dans la BDD. Ici, aucune donnée vraiment secrète ne transite en clair via Internet. J'espère que je suis compréhensible cette fois-ci ...
4 juil. 2011 à 17:12
Il y a erreur dans le titre le cryptage n'a rien à voir avec une clé "md5", "sha", "haval"... hormis le https mais ne nous attardons pas sur ce détail ^^ Ce n'est pas plus sécurisé parce qu'on HASH en "md5", "sha".... car ça se contourne, ça tout le monde le sait hein !
@stay, je cite :
"Je crois qu'aujourd'hui, magic_quotes_gpc : cette fonctionnalité est OBSOLETE depuis PHP 5.3.0... Je travaille la plus par du temps avec des Frameworks et elle contienne une librairie intéressante pour la sécurité..."
- Alors là raison de plus pour tester que tes scripts soit portables car tous les serveurs ont des versions différentes et attention aux surprises ! Zend c'est un excellent Framework (j'ai pu voir la team à l'AFUP en 2010 ça n'enlève pas qu'il ne faut pas omettre en tant que développeur qu'il est possible de changer souvent de config, de servers / partager ses scripts) donc prudence. ;)
Sinon cette source c'est du vu et revu essaye de passer à la POO ...
3 juil. 2011 à 22:49
Ce qui est logique.
Tu proposes de le hasher avant l'envoi et tes explications sont inutiles car, pas compris.
Voilà, là j'ai eu ma dose.
PS : j'ai rarement des difficultés à comprendre une idée mais là, désolé.
3 juil. 2011 à 13:48
3 juil. 2011 à 12:30
Si je peux partager ma passion et mes connaissances :).
3 juil. 2011 à 11:55
Je pense qu'avec ça , je decouvre une autre facette de langage sympathique...
Merci encore a toi ,
Je reviendrai vers toi pour plus d'infos si tu m l permets
3 juil. 2011 à 11:30
Aujourd'hui les employeurs potentiels désirent travailler avec des solutions robustes et gratuites.
Zend qui à créé PHP (http://fr.wikipedia.org/wiki/Zend_Technologies) propose un Framework Open Source.
Tout est en objet et très puissant.
Ce n'est pas la solution incontournable pour codé, mais elle fait partie des solutions à connaitre dans ton bagage.
Voici un tuto : http://julien-pauli.developpez.com/tutoriels/zend-framework/presentation/
Pour la librairie : http://framework.zend.com/manual/fr/
Pour l'exemple que j'ai utilisé avec Zend_Table : http://framework.zend.com/manual/fr/zend.db.table.html
Si tu as d'autre question, n’hésite pas :)
3 juil. 2011 à 11:18
Donc, ma question n'a plus de sans : Ok, tu propose de l'hasher de quel façon quand tu dis avant de l'envoyer ?
Vue que au final, tu fais comme moi et bm1982.
Tu as dis : Je disais que ça serait une bonne idée de hasher (via MD5, SHA ou n'importe quoi d'autre en fait) le mot de passe avant de l'envoyer. Là il passe en clair (sauf si on travaille en HTTPS mais c'est moins souvent le cas), n'importe qui peut l'intercepter ... Quand je dis que ça ne gène personne, je veux dire que beaucoup d'autres gens font la même chose et que ça n'est pas vraiment une bonne idée !
@ghuysmans99 : Tu dis que n'importe qui peut l'intercepter et que cela ne nous gène pas. De quoi tu parle ?
Car si hasher est une bonne idée, je ne te suis plus !
3 juil. 2011 à 11:04
3 juil. 2011 à 10:33
Mais moi je suis un debutant , et vous utilisez des termes de niveau big pour moi ...
Alors sans vous offensez , utilisez des termes plus claires ou encore elucidez les d'exemples
3 juil. 2011 à 10:29
Pour la sécurité des requêtes SQL, je ne code plus de cette façon depuis longtemps.
Les POST que j’envoie à un SELECT ou ,... passe toujours par un bind pour la sécurité.
Et il ne faut plus ce préoccupé des magic quotes.
Je crois qu'aujourd'hui, magic_quotes_gpc : cette fonctionnalité est OBSOLETE depuis PHP 5.3.0.
http://php.net/manual/fr/info.configuration.php
Je travaille la plus par du temps avec des frameworks et elle contienne une librairie intéressante pour la sécurité.
Genre, avec Zend_table.
$id = $_POST['id'];
$u = new self();
$select = $u->select();
$select->where('id = :id');
$select->bind(array(':id' => $id));
$user = $u->fetchRow($select);
return (object) $user;
3 juil. 2011 à 08:18
3 juil. 2011 à 00:43
Pour le sha1, tu exagères pas un petit peux car le sujet est bien d'améliorer positivement un code.
Tu viens avec tes gros sabot avec t'as phrase "On dirait que ça ne gène personne".
Du calme, si tu dis quelque chose d’intelligent à dire sans monter dans le ton. Cela passera pareil tu crois pas ?
Et pour ton détail : mysql_real_escape_string protège les injections dans la base de donnée.
Voici ce qui est écrit ici, http://php.net/manual/fr/function.mysql-real-escape-string.php : Cette fonction doit toujours (avec quelques exceptions) être utilisée pour protéger vos données avant d'envoyer la requête à MySQL.
Tu propose de ne pas l'utilisé mais, tu ne donnes pas de solutions intermédiaire pour les injections et ça, cela ne te gène pas ... pour reprendre ta phrase ?
2 juil. 2011 à 22:59
Autre gros détail : en fonction de la config du serveur, les single quotes seront échappées une ou deux fois. Il ne faut appliquer mysql_real_escape_string que lorsque get_magic_quotes_gpc est nul.
2 juil. 2011 à 20:16
en français : http://jquery.jarodxxx.com/ ;)
2 juil. 2011 à 20:14
ta pa une doc intéressante sur JQUERRY
2 juil. 2011 à 20:10
Comme cela tu fais un premier test en JavaScript pour tester les champs et faire un retour en json.
Donc, pour la sécurité, un premier test avec la librairie : http://docs.jquery.com/Plugins/validation.
Par la suite si la validation est à true.
Tu envoies en ajax avec la librairie : http://api.jquery.com/jQuery.ajax/.
En data dans ce même envoi, tu serialize tout ton form.
$.ajax({
url: $.connectionBo.url+'access/',
type: 'POST',
data: $('form').serialize(),
dataType: 'json',
success: function(json) {
if(json.access == true) {
document.location = json.out.url;
} else {
$.jGrowl(json.msg);
}
}
});
si accès est = à true, y a la redirection ou bien un message est retourné.
Bien sur le message retourné est l'erreur d'avoir mal tapé son mot de passe.
Mais si un petit malin modifie mon html pour me hacker et fait sauter le premier test jquery.
Le test en php est à faire, et donc, tu renvois un message lié à ce que tu veux :)
La librairie jGrowl pour les messages : http://stanlemon.net/projects/jgrowl.html#samples
Je suis de bonne humeur, c'est analyse coute chère.
Il y a beaucoup d'information, et beaucoup à refaire, mais cela va t'amuser de travailler de cette façon :).
2 juil. 2011 à 19:22
Je l'etudierai ...Encore lot of thanks
Et pour la recupération des POST , Les redirections , Que penses-tu ?
2 juil. 2011 à 19:16
return (string) sha1($password);
2 juil. 2011 à 19:14
Mais, on peut créer une session plus complexe.
Le champ token est généré automatiquement comme tu fais avec le md5.
Mais ce champs serait régénéré si l'utilisateur clique sur log-out.
Si l'utilisateur coupe son navigateur, il sera délogé et le token serait le même pour la prochaine session et sans problème de sécurité.
Et bien sur, le token serait un code généré en sha1.
Voici un très bon exemple dans une class :
/**
* Number of characters for the password
*
* @access public
* @static
* @var int
*/
public static $numberCharForPassword = 8;
/**
* Get password or token
*
* @author Stay
* @access public
* @static
* @return string $password
*/
public static function getSha1 ()
{
$s = "abcdefghijklmnopqrstuvwxyz";
$s .= "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$s .= "0123456789";
$s .= "@";
$password= "";
for($u = 1; $u <= self::$numberCharForPassword; $u++) {
$nb = strlen($s);
$nb = mt_rand(0,($nb-1));
$password .= $s[$nb];
}
return (string) $password;
}
2 juil. 2011 à 18:51
2 juil. 2011 à 18:49
Pour la variable $pass et $pass_user , c'est une erreur , j admets et remercie bocoup.
En ce qui concerne le token , selon toi , elle pourrait permettre de savoir si une session est ouverte ....ou fermé ...
mais les utilisateurs , n'ont pas la meme maniere de fermer l'application(soit deconnexion , soit fermeture browser...etc)...
Puis je avoir ce que le token ferra exactement....
En tout cas, je te remercie pour ton aide...
merci
2 juil. 2011 à 18:14
Tu as fais une première erreur sur la variable $pass, connexion pour la db, alors que tu la nomme $pass_user à la ligne numéro 7 du fichier enregistrer.php.
Par la suite, l'insert ne peut fonctionner car, tu insères id = '' dans un champ integer.
Pour le cryptage, je te propose la fonction sha1 qui est bien plus efficace.
Et pour la table tus_ac12, je te propose un champ supplémentaire pour un token.
token : char(40), tu pourrais l'utiliser pour garder la session ouvert et la modifier avec un log-out pour la prochaine session.
$_SESSION['login_1'] = $token;
Si tu as des questions, n'hésite pas.
2 juil. 2011 à 17:02
Dezypé le Tar Yo , et le script de la base y est et aussi les fichiers neccessaires.
Au démarrage , vous êtes redirigé automatiquement vers la page de connexion qui est homepage.php
Sur cette page , vous pouvez vous inscrire ou recuperer votre mot de passe(Non fonctionnel)ou encore vous connecter a l'application.
A la creation de votre compte, votre password subit un cryptage avant son insertion dans la base.
Lorsque vous renseigner les zones login et password , ces derniers subissent u n cryptage aussi .
Ensuite ils sont soumis a un controle .
Si les 2 sont bons alors vous êtes redirigés vers la page de bienvenue
homepage.php---------> pretups6000get.php----------->menu.php
Un fichier nommé config.php , comprend vos differents parametres ...
//////////////////////////////////////////////////////////////////////////////////////////////
Je veux des critiques et suggestions
////////////////////////////////////////