Discussion :

[farid126]

Bonjour
je suis entrain de crypter des données sur une base donnée Mysql en utilisant
les fonction suivantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AES_ENCRYPT(str,key_str), AES_DECRYPT(crypt_str,key_str)

et j'ai lu quelque part que en peux éviter de transmettre la clé en clair en la stockant dans une variable sur le serveur au moment de la connexion.
ma question est comment stoker cette clé dans le serveur mysql ? et comment la récupérer pour déchiffrement ?
merci pour votre réponse.

[Invité]

Salut,
alors il y a plusieurs chose dans ta question.

1- La première c'est que si tu veux vraiment être sécurisé lorsque l'internaute tape son login/mot de passe sur internet il faut une connexion SSL (ou technique javascript... mais pas terrible) vaut mieux dépenser un ti billet pour le SSL si tu veux vraiment être sécurisé.

2- Ce qu'il faut c'est hacher le mot de passe (avec SHA256 par exemple) + ajouter un grain de sel + ajouter le login dans la même variable et ajouter celle ci dans la base de donnée. Ensuite tu pourra comparer cette valeur.
Le fait de concatener le login à ton mot de passe le rendra unique. Voici une discussion sur ce sujet

+ Fait quelques recherches sur le hash + le grain de sel

[SQLpro]

...
2- Ce qu'il faut c'est hacher le mot de passe (avec SHA256 par exemple) + ajouter un grain de sel + ajouter le login dans la même variable et ajouter celle ci dans la base de donnée. Ensuite tu pourra comparer cette valeur....

je suis toujours attéré de lire des stupidités pareilles !!!!
faut-il rappeler que
UN HACHAGE N'EST PAS UN CRYPTAGE !!!

A +

[Invité]

@sqlpro : j'ai parlé de "cryptage" pour le ssl et du hachage pour le mot de passe , il y a quelque chose de faux la dedans ? Éclaire moi je vois pas mon erreur...
L'utilisateur ne donnant pas trop de détails j'ai essayé de comprendre ce qu'il voulait et je pensais qu'il voulait se connecter à sa base à partir d'une page web en toute sécurité et protéger son mot de passe dans la base.

[ericd69]

salut,
sqlpro a raison:

• le hashage n'est pas une bijection, il n'est pas réversible car plusieurs valeurs de départ peuvent avoir un même hashage... on cherche donc à collisionner, c'est à dire à trouver l'une des valeur qui donne le hashage pour le casser...
• le cryptage est une bijection. à un cryptage correspond une et une seule valeur de départ. pour le casser, il faut donc trouver cette valeur...

de toute façon si tu veux des échanges sécurisés entre navigateur et le serveur faut passer par ssl... c'est clair.

sinon on choisit souvent de placer un fichier hors de l'arborescence accessible par le serveur web mais accessible via ftp... comme ça depuis un fichier php tu peux y accéder mais pas de risques avec des tentatives depuis un navigateur du moment que tu as bien protégé tous tes répertoires web...

[Invité]

Je dis pas que sqlpro à tord au contraire mais je pense qu'il à pas compris ou je voulais en venir ou c'est moi qui ai loupé un truc.

[ericd69]

je pense que toi tu as assimilé sa demande à un traitement de mot de passe alors que lui parle de données en général je pense... d'où pas de hashage du tout

[SQLpro]

Je dis pas que sqlpro à tortd au contraire mais je pense qu'il à pas compris ou je voulais en venir ou c'est moi qui ai loupé un truc.

Au passage vous avez tort avec un T comme tortue et non pas comme tordu !

la question initiale était :
je suis entrain de crypter des données
le fait ce crypter le transport n'a rien à voir avec le cryptage des données de la base. le jour ou l'on vous volera les fichiers de la base (voire les sauvegardes) vous comprendrez peut être la différence.

De toute façon le cryptage dans MySQL est plus que lamentable ce qui fait qu'il est systématiquement recalé dans les audits de sécurité notamment dans le domaines des applications de santé !
Ce n'est pas, loin sans faut, l'un des seul défaut de cet ersatz de SGBDR... A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

De même hélas pour PostGreSQL !

A +