Discussion :

[RS-28]

Bonsoir,

Je me perd encore pas mal au niveau de la compréhension du chiffrement.

Je sais que le hash permet de donner une emprunte à un mot de passe, le hash est donc à sens unique. Et s'est cette informatique qui sera inscrite dans ma base de donnée (et non le mot de passe en clair).

Mais j'aimerais comprendre bien donc j'aurais 2-3 questions:

1. AES-256 lui, permet de sécuriser l'échange d'informations entre un serveur et une base de donnée s'est bien ça ?

2. Un utilisateur se connecte avec son mot de passe sur mon site, son mot de passe est d'abord hasher, puis chiffré et je dois donc le déchiffrer dans ma base de donnée ?

3. Pour suivre la question n°2, il faut que je déchiffre cette échange dans ma base de donnée s'est ça ? Si c'est le cas, j'ai du mal à comprendre cette partie là. Si je dois déchiffrer dans ma base de donnée un quelconque échange entre le serveur et la base de donnée, j'imagine que la clé dois donc être une clé hashée elle aussi qui elle même est stockée dans une table de ma base de donnée pour rendre ça automatique ?

Je regarde 56 exemples et ce ne sont que des exemples entre 2 clients, mais il n'y a aucune base de données j'ai donc du mal à comprendre certaines choses dans ce genre de cas, merci pour votre aide !

[Invité]

Bonjour,

tu ne parles pas du langage serveur que tu utilises.

Si c'est PHP :

• password_hash()
• password_verify()

1- Lorsqu'on CREE un nouvel utilisateur (donc nouveau mot de passe) :

• on utilise password_hash() avant de l'enregistrer en BDD.

2- Quand l'utilisateur se connecte :

• il entre son login et mot de passe (en clair)
• on requête en BDD pour trouver le login
• on compare le mot de passe (en clair) avec celui en BDD (hashé) grâce à password_verify()

[ABCIWEB]

Salut,

Le cryptage est utilisé pour crypter des messages, des documents qui devront ensuite être décryptés pour pouvoir lire l'original. AES 256 suppose une clé publique et une clé privée. C'est sécurisé tant que ta clé privée n'est pas piratée car il faut bien la stocker quelque part.

Le hash a cet avantage qu'il ne nécessite pas de stoker de clé quelque part. On s'en sert pour les mots de passe car on a pas besoin de retrouver l'original. Si je hash 'abc' cela va me donner le hash de cette chaine et c'est ce hash que je vais stocker en bdd. Quand tu récupère le mot de passe rentré dans le formulaire d'authentification, tu hash cette valeur et tu compare si elle correspond au hash enregistré en bdd.

Evidemment cela suppose qu'un hash soit unique c'est à dire qu'on ne puisse pas trouver deux (ou plus) valeurs qui donneront le même hash. C'est pour cela que cela évolue et que par exemple l'ancêtre MD5 a été remplacé par SHA puis SHA2, SHA3.
Il existe des solutions plus évoluées comme la fonction password-hash de php par exemple qui génère un sel pour éviter qu'un pirate utilise un dictionnaire de hash, et on peut aussi définir le coût machine nécessaire pour se protéger au mieux des attaques force brute (tester toutes les possibilités sans dictionnaire préalable). C'est donc cette fonction qui est recommandée si on utilise php côté serveur.

Donc l'éthique veut qu'on utilise jamais le cryptage pour les mots de passe, mais uniquement des hash. Si un pirate récupère ce hash il sera obligé de faire tourner sa machine (ou son réseau de machines) un certain temps pour essayer de trouver la chaine correspondante par force brute, et cela pour chaque mot de passe, donc un temps suffisamment long (c'est le but) pour qu'on prévienne les utilisateurs de changer de mot de passe si l'on s'est aperçu du piratage. Alors que si un pirate peut récupérer la clé privée d'un cryptage, le décryptage est instantané.

[RS-28]

Merci pour vos explications, ça m'a bien éclairé !

Du coup s'est selon le cas d'utilisation, si je suis censé connaitre l'information de départ ou pas.

Dans mon cas ce seras bien du hash alors dont j'aurais besoin.

Sinon coté serveur j'utiliser java ou php.

[ABCIWEB]

Oui pour les mots de passe c'est obligatoirement du hash. Sinon en cas de piratage des données, l'utilisateur pourrait te poursuivre pour n'avoir pas utiliser les techniques adéquates (faute professionnelle). D'autant plus que le serveur ne doit pas être en mesure de décrypter les mots de passe car c'est une donnée confidentielle appartenant à l'utilisateur.

Pour l'anecdote, il y a quelques années on trouvait sur certains sites des procédures pour pouvoir récupérer son mot de passe, ce qui veut dire qu'il était soit stocké en clair, soit crypté. Tu ne trouveras plus cela maintenant. En cas de perte, on envoi un lien pour choisir un autre mot de passe et non pas pour le récupérer.

[snobelix]

Bonjour,

Petit point de vocabulaire qui me chiffonne, l'utilisation du terme crypter signifie qu'il n'y a pas de retour arrière possible. Alors que l'on peut chiffrer et déchiffrer une information.
1) Sinon pour sécuriser ton échange serveur/bdd, tu peux utiliser du TLS ce qui permet un transfert d'information dans un canal sécurisé.
2) Le hash du mot de passe sera envoyer au serveur (si tu utilise du javascript) sinon le hash se fera sur le serveur puis tu auras juste à comparer le hash généré et celui en bdd.
Pour un information le SHA-384 limite le risque de collision (2 chaînes caractères ayant la même empreinte après le calcul de leur hash).

[Invité]

... l'utilisation du terme crypter signifie qu'il n'y a pas de retour arrière possible...

Faux.
On parle de cryptage et de décryptage (grâce à une ou plusieurs clés de cryptage).

Contrairement au hashage (hachage), théoriquement irréversible.

[ABCIWEB]

Bonjour,
Petit point de vocabulaire qui me chiffonne, l'utilisation du terme crypter signifie qu'il n'y a pas de retour arrière possible. Alors que l'on peut chiffrer et déchiffrer une information.

Oui tu as raison et tu fais bien de le souligner. J'oppose cryptage et hashage alors que je devrais opposer chiffrement et hashage.

Des restes de longues lectures dans des forums qui faisaient souvent cette approximation qui n'est pas gênante quand on pense en termes littéraires - cryptographie et donc intuitivement crypter/décrypter - mais qui prête à confusion et il faut être plus rigoureux quand on parle de chiffrement et de sécurité informatique. Cela fait des lustres que je le sais, cette fois-ci je fais mon méaculpa par écrit en espérant que ça rentre mieux et ne plus perpétuer cette mauvaise habitude

[ABCIWEB]

Faux.
On parle de cryptage et de décryptage (grâce à une ou plusieurs clés de cryptage).

Contrairement au hashage (hachage), théoriquement irréversible.

Oui dit comme ça évidemment c'est clair et c'est dans ce sens que j'utilisais cette expression. Mais cela prête à confusion.

Par exemple pourquoi utilise-t-on la fonction crypt de php pour faire du hashage ? Selon "notre définition" cela suppose que le cryptage peut être parfois réversible mais parfois non. En parlant de chiffrement on évite cette ambiguïté.

[Invité]

• Chiffrement

Le chiffrement ou cryptage, est un procédé de cryptographie grâce auquel on souhaite rendre la compréhension d'un document impossible à toute personne qui n'a pas la clé de (dé)chiffrement...............

Et si en plus, on ajoute les "équivalents" en anglais, on n'a pas fini !

[RS-28]

J'ai aussi une autre question, j'utilise la fonction içi en php:

Code PHP :

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

1
2
3
4
5
6
7
8
function hashFunction($element)
{
  // Must be exact 32 chars (256 bit)
  $element = substr(hash('sha256',$element, true), 0, 32);
  return utf8_encode($element);
}
 
Ce qui me donne ceçi : ø`ùâkj9Ö`'ÞR»€im’áeÔ=Ää"Ÿ¤)¹ð

Ce code que je reçoit je l'inscrit donc dans la base de donnée en tant que mot de passe de l'utilisateur, mais on m'a fait savoir que si ce hash transite tous le temps en gardant la même tête, voir ce hache ou voir mon mode passe en clair reviens au même. Je ne comprend pas trop si l'idée de départ est que pour se connecter à mon site il faut le mot de passe en clair, et que le hash est sencé être irréversible.

Auriez vous une petite explication pour moi s'il vous plait ? Merci encore pour tous vos conseilles.

En attendant j'ai pris la solution que vous m'avez proposé en PHP et qui marche très bien, en espérant que ce genre de solution sois aussi disponible en Java ou en C#:

Code PHP :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
$password = 'toto28';
$salt = date("Y/m/d"); // date et heure d'inscription
$hash = hashFunction($password);
 
echo 'Avant: '.$salt.$password.' Après: '.$hash.'<br>';
 
echo 'est-ce que il sera identique si je le vérifie?<br>';
 
echo 'reponse: ';
 
if(passwordVerif($password, $hash))
{
  echo 'oui';
}
else
{
  echo 'non';
}
 
function passwordVerif($password, $hash)
{
  // Renvoit true ou false
  return password_verify($password,$hash);
}
 
function hashFunction($element)
{
  // Must be exact 32 chars (256 bit)
  $element = password_hash($element,PASSWORD_DEFAULT);
  return $element;
}

[ABCIWEB]

...on m'a fait savoir que si ce hash transite tous le temps en gardant la même tête, voir ce hache ou voir mon mode passe en clair reviens au même.

Tu parles de la transmission des données ce qui est un autre problème dont on parlait fréquemment dans l'ancien temps (il y a quelques années) quand l'accès au https était couteux. Pour éviter qu'un pirate sniffe le réseau et regarde les données que le visiteur envoie, on hashait le mot de passe côté client en javascript. Mais si cela permettait d'éviter que le pirate connaisse directement le mot de passe, cela ne l'empêchait pas de se connecter en envoyant ce hash vers le serveur. On ajoutait donc un salt variable que l'on collait au mot de passe, avant de hascher l'ensemble en javascript et de l'envoyer vers le serveur soit grosso modo : sha(salt+sha(mdp)).

Mais ce n'était pas parfait :
- D'une part cela empêchait de mettre un salt dans le hashage du mot de passe enregistré en bdd, on perdait donc en partie d'un côté ce que l'on gagnait de l'autre.
- Et même si le piratage de la bdd est normalement plus difficile que le piratage du réseau, ce qui rendait cette solution plutôt pertinente, un pirate ayant accès au réseau pouvait aussi récupérer les cookies de session et donc pirater la session utilisateur sans avoir besoin de s'identifier par mot de passe.
Bref c'était mieux que rien, mais loin d'être idéal en termes de sécurité.

C'est pour cette raison que tout le monde s'est mis au https qui est maintenant disponible sur des mutualisés y compris entrée de gamme (chez OVH par exemple). Ainsi le mot de passe est envoyé en clair (sans traitement javascript) mais protégé par le chiffrement du réseau, ce que ne faisait pas le protocole http. Côté bdd cela permet de rajouter un sel dans l'enregistrement du hash, et donc on a largement gagné en sécurité à tous les niveaux.


Laisses tomber tes fonctions car même sans être un expert en sécurité je peux te dire qu'il y a des incohérences dans ton système.
- Déjà tu ne prends que les 32 premiers caractères de ton hash ce qui réduit sa singularité.
- Ensuite créer un salt avec la fonction date, c'est pas bon, il faudrait utiliser openssl_random_pseudo_bytes ou random_bytes pour créer un salt digne de ce nom.

Mais bon t'embête pas et utilises les fonctions que l'on t'a conseillées à savoir password_hash et password_verify. Il faut absolument éviter les improvisations tant que l'on est pas un expert confirmé, surtout dans le domaine de la sécurité informatique. Ces fonctions sont conçues pour offrir un maximum de protection en évitant aux développeurs de faire du bricolage et des solutions hasardeuses finalement peu sécurisées, alors pourquoi t'en priver ?

[RS-28]

Un très grand merci, j'ai maintenant bien compris ! J'ai eu du mal à dormir cette nuit à cause de ça lol....

Je partait en impro sûrement car je n'avais pas assez de connaissances et donc pas mal de tutoriels sur le net proposes des solutions qui ne sont plus trop d'actualités ou qui manque d'explications.... Mais bon.

J'ai bien compris maintenant qu'avec password_hash et password_verify + un https ça devrais suffire et ce sans personnaliser quoi que ce soit comme j'ai montré précédemment.

Un grand merci pour cette attention, c'était une chose importante qu'il fallait que je sache.

Cette offre d'OVH m'assure donc un protocole sécurisé pour le transfert de données avec un certificat ?


SSL Gateway Advanced
Pour un site Professionnel à trafic modéré : e‑commerce, PME/Start-up, web agency

Anti - DDoS
Métriques incluses (1 Mois)
Load Balancing
IP dédiée
Certificat EV en option
-
-


20,00 €
HT/mois (soit 24,00 € TTC)

J'ai tellement de questions... Je suit des cours en programmation à la haute école et je sais que ce sont 2 métiers différents. Il y a donc du coté client, du coté transfert et du coté base de donnée qu'il faut sécuriser. Coté client je comprend, coté base de donnée avec un hash comme vous m'avez donné ça devrais suffire. Et donc coté transfert on a le choix entre chiffrement/déchiffrement (SSL) avec AES-256 par exemple ou bien un certificat que le serveur propose moyennant une certaine somme si j'ai bien compris ? Ce seras ma dernière question car je ne vais pas abuser lol

[ABCIWEB]

Cette offre d'OVH m'assure donc un protocole sécurisé pour le transfert de données avec un certificat ?
SSL Gateway Advanced
20,00 €
HT/mois (soit 24,00 € TTC)

C'est une option payante pour avoir ce qui ce fait de mieux, avec des certificats individualisés et très sécurisés. Dans un premier temps pour un site pro à trafic modéré, tu pourrais choisir l'offre PRO à 6 EHT/mois et utiliser SSL Gateway Free, donc sans coût supplémentaire pour avoir ssl (https). Cela permet de démarrer à moindre frais, et si besoin tu pourras upgrader cette offre vers une plus puissante, et si besoin aussi utiliser l'option ssl payante pour avoir un maximum de sécurité. Mais disons que l'offre gratuite est déjà pas mal et permet de traiter le minimum essentiel.

Il y a donc du coté client, du coté transfert et du coté base de donnée qu'il faut sécuriser.

- Côté client, avec php il faut protéger ce que tu affiches avec la fonction echo ou sa forme raccourcie <?= avec htmlspecialchars pour éviter que php interprète des données utilisateur qui ont été enregistrées dans une base de donnée par exemple. Pour le reste html/css et javascript sont visible dans le navigateur donc mieux vaut se dire qu'on ne peut pas les protéger et compter sur les contrôles côté serveur.
- Côté transfert utilises un hébergeur qui permet au moins le SSL Gateway Free, cela concerne donc le choix de l'hébergement et éventuellement les options.
- Côté bdd, avec php il faut utiliser PDO et impérativement des requêtes préparées pour éviter les injections sql.
- Côté serveur, en complément des données qui seront enregistrées en bdd avec PDO il faut faire attention aux scripts sensibles comme l'upload de fichier, l'effacement de fichiers, le téléchargement de fichiers (liste non exhaustive).

Donc pour conclure tu peux commencer par l'offre PRO (ou même l'offre PERSO que tu pourras upgrader également si besoin), tu actives ensuite l'option gratuite SSL dans ton espace administrateur OVH et basta, ça roule pour le https. Cela te permettra déjà de commencer sur de bonnes bases et ça te laissera le temps d'apprendre et de savoir si tu as besoin de plus de puissance ou plus de sécurité que tu pourras toujours ajouter en upgradant ton offre vers une supérieure ou en ajoutant des options d'un simple clic.

[RS-28]

Un énorme merci à vous tous pour ces explications, je voit beaucoup plus clair et vous avez répondu parfaitement à mes question en y consacrant beaucoup de temps.

Je met ce sujet en résolut et je sauvegarde tous ça.

Bien à vous !