Topic des salaires et des carrières : Les SouSous dans la popoche

[C4nard]

Si : dans le cas d'une base de données leakée, si le mot de passe est salé (et que le sel n'est pas connu) les gens ne pourrons pas remonter jusqu'au mot de passe d'origine qui peut être utilisé ailleurs si jamais le hash est renversé par la technique dont tu parle après :

En effet, par contre pour peu que tu connaisses un mot de passe de base (par exemple ton propre compte qui ferait parti de la fuite), tu peux facilement retrouver le sel et donc tu peux repartir sur l'algo de base (même si les tables précalculées ne fonctionneront pas du coup).

[Anonyme20240202]

Ouais enfin je suis pas idiot, je dis pas ça méchamment mais bien évidemment que quand je dis "décrypter le hash" ça sous entend le travail inverse que tu décris. J'utilise décrypter dans le contexte d'utiliser md5 comme méchanisme d'encryption (indépendamment de la notion de clef, mais tu fais bien de noter la subtilité).

Le problème du salt c'est que c'est une solution d'enfant. Ca n'augmente pas suffisamment la complexité calculatoire, ça ne change pas grand chose. MD5 est toujours aussi rapide à calculer. Tu peux calculer 10 milliards de valeur par seconde avec un GPU pourrave. Suffit de voir les benchmark de hashcat ou autre, même avec tes passwords "plus longs".

Alors que la porte d'à côté tu as des algorithmes qui permettent de consumer des niveaux de ressources impossible à réaliser en pratique (bcrypt etc.).

Pourquoi prendre le risque, c'est simplement pas l'outil pour. Surtout que la moindre information annexe quant aux données initiales facilite encore la tâche. Donc bref, à éviter, vouloir réinventer la roue en partant de "md5 plus ma tambouille maison" c'est pas fou.

Et une fois la tambouille maison découverte, tu fais tomber la totalité de la cache secrète d'ailleurs, vraiment naze, 'fin bon je suis sûr qu'on pourrait énumérer les divers problèmes de cette approche pendant longtemps

[Cheshire]

En effet, par contre pour peu que tu connaisses un mot de passe de base (par exemple ton propre compte qui ferait parti de la fuite), tu peux facilement retrouver le sel et donc tu peux repartir sur l'algo de base (même si les tables précalculées ne fonctionneront pas du coup).

C'est ça que je ne comprends pas, pour retrouver le sel avec juste une combinaison mot de passe + md5(mot de passe + sel), il faut le faire par force brute c'est bien ça ?

Si le sel fait même à peine 20 caractères (parmi disons 50 possibles en comptant lettres, chiffres et symboles), ça fait 50^20 possibilités, soit dans les 10^34 ; même avec 10^10 valeurs testées par secondes on reste encore très loin de quelque chose de réalisable avant l'extinction de l'univers... Ou alors en ayant plusieurs combinaisons mdp/md5 il y a moyen de réduire le temps de calcul ?

[Garrluk]

Mais le sel n'est jamais secret, il faut qu'il soit accessible par le serveur au moment de la connexion pour vérifier le mot de passe entré par l'utilisateur (en gros le serveur va vérifier que md5(mdp + sel) == mdp_bdd).
Donc si les mots de passe ont leakés, le sel se retrouve dans la nature avec le reste.
La seule protection que ça apporte c'est que ça empêche de précalculer les hash et d'en faire des rainbow tables, mais une fois que quelqu'un accède à la base il peut trouver les mots de passes sans problèmes.

Après ce que critique Kamikaze, ce n'est pas l'utilisation du sel, c'est l'utilisation de md5.
Les autres algos de chiffrages (genre bcrypt) utilisent aussi le salage

[Wingi]

Merci pour vos retours
A mon niveau, tout à l'air d'être dans les clous niveau légal (même si bon, je ne suis pas juriste). Du coup, je suis transparent, et si ce n'est pas une SSII, il n'y a pas de concurrence, c'est noté !

[deathdigger]

Mais le sel n'est jamais secret, il faut qu'il soit accessible par le serveur au moment de la connexion pour vérifier le mot de passe entré par l'utilisateur (en gros le serveur va vérifier que md5(mdp + sel) == mdp_bdd).
Donc si les mots de passe ont leakés, le sel se retrouve dans la nature avec le reste.
La seule protection que ça apporte c'est que ça empêche de précalculer les hash et d'en faire des rainbow tables, mais une fois que quelqu'un accède à la base il peut trouver les mots de passes sans problèmes.

Après ce que critique Kamikaze, ce n'est pas l'utilisation du sel, c'est l'utilisation de md5.
Les autres algos de chiffrages (genre bcrypt) utilisent aussi le salage

Une bdd peut avoir été piratée sans que le code du site (et donc la logique du salage) ne le soit.

[vv221]

Du coup, si je leur dis que je pars, ils vont sans doute chercher à savoir où, pour me coller ça sous le nez le cas échéant, ou lever cette clause pour ne pas avoir à me payer.

J’ai toujours eu cette clause dans mes contrats.
J’ai jamais eu un employeur qui soit prêt à me payer après mon départ plutôt que de la faire sauter (dommage ).

---

Je bosse un peu avec l'ANSSI (l'organisme d'état référent sur la cybersecurité) et ils sont en galère totale de personnel.

Mince, « L’ANSSI recrute ! » était déjà leur devise officieuse la première fois que j’ai croisé du monde qui y bosse, et pourtant ça remonte à un paquet d’années…

[ook4mi]

La cyber sécurité est un secteur ultra porteur, surtout depuis deux ans j'ai l'impression. C'est un excellent moment pour s'y lancer je dirais.
J'ai bien vu quand je cherchais du boulot en revenant d'Irlande mi 2019 et en début de cette année, le nombre de postes dans le réseau (que ce soit en tant qu'ingé ou archi) qui demandait des compétences en sécurité, voire des postes 100% dédiés sécurité, a complètement explosé. Et tant qu'il y aura de l'informatique, il y aura de la demande en sécurité informatique, sur le long terme tu es relativement tranquille.

Après, je sors de mon domaine donc niveau formation je ne vais pas pouvoir t'aider. Je dirais juste que c'est important d'avoir des bases solides en réseau : forcément, si tu dois faire de la sécurité info, il faut avoir une idée de comment fonctionne ce que tu vas être amené à sécuriser

héhé totalement d'accord d'ou mon envie de monter en compétence dans le domaine.

Ca dépend de ce que tu t'imagines faire et quelle équilibre tu veux entre la "technique" et la "théorie"
Tu peux vouloir développer des produits utilisés dans la cybersécurité (quels sont les mécanismes internes au produit pour s'assurer que c'est pas contournable).
Tu peux déployer en pratique des produits de cybersécurité dans ta société en tant que RSI (vérifier que tout est bien fait dans les règles de l'art).
Tu peux définir des politiques globales de sécurité de ta société en tant que RSSI (mettre en oeuvre des processus, vérifier que tu coches bien toutes les cases de la réglementation)
Tu peux faire des audits de produit et/ou de société pour délivrer des certifications en tant que consultant (faire passer des batteries de tests)
Quelques exemples parmi d'autres.

Globalement la cybersécurité c'est un domaine plutôt en vogue en ce moment (a peine ). Je bosse un peu avec l'ANSSI (l'organisme d'état référent sur la cybersecurité) et ils sont en galère totale de personnel.

Franchement je trouve pour le moment tout hyper intéressant mais cela fait quelques années que j'ai pas fait de code donc je pense que je serais plus sur la partie déployement et définir des politiques globales.

Bref, y a une longue montée en compétence à faire je pense... Surtout que je trouve le domaine assez fermé sur lui-même, j'avais un contact mais dès que j'ai refusé sa proposition d'entretien : il a disparu... . Je prépare une présentation pour défendre mes demandes de formation et voir si cela passe...

Tu bosses avec l'anteine Lilloise de l'Anssi ?

Merci

[Garrluk]

Une bdd peut avoir été piratée sans que le code du site (et donc la logique du salage) ne le soit.

Ça peut arriver mais ça ne change rien. Déjà parce qu'il n'y a pas trois cent mille moyen différents de saller donc tu peux retrouver le mot de passe quand même.
Et surtout, il ne faut pas se reposer dessus parce que ça veut dire que si le code et la base venait à leak tu n'assurerais plus la sécurité des mots de passes. Autant utiliser directement bcrypt correctement, comme ça il fait le salage et le chiffrage pour toi et même si la base et le code se retrouvent dans la nature les mots de passe seront protégés.

[Nortifer]

Mince, « L’ANSSI recrute ! » était déjà leur devise officieuse la première fois que j’ai croisé du monde qui y bosse, et pourtant ça remonte à un paquet d’années…

Ouais, ça doit pas être un si bon plan que ça, j'ai eu 3 interlocuteurs différents en un an

Tu bosses avec l'anteine Lilloise de l'Anssi ?

Je suis chez un éditeur de logiciel, et je sollicite l'ANSSI pour qu'ils mettent un tampon sur nos produits pour certifier qu'ils sont sécurisés. Je crois que le bureau qui s'occupe de ça est a Paris.
Sauf que en ce moment ça avance pas faute de dispo de leur côté

[Dross]

Ça peut arriver mais ça ne change rien. Déjà parce qu'il n'y a pas trois cent mille moyen différents de saller donc tu peux retrouver le mot de passe quand même.
Et surtout, il ne faut pas se reposer dessus parce que ça veut dire que si le code et la base venait à leak tu n'assurerais plus la sécurité des mots de passes. Autant utiliser directement bcrypt correctement, comme ça il fait le salage et le chiffrage pour toi et même si la base et le code se retrouvent dans la nature les mots de passe seront protégés.

Oui bcrypt et autre algo que md5 seront mieux. Mais faire du FUD c'est pas cool néanmoins.

Et si il y a trente-six mille moyens de saler : tu peux générer différents types de sels pour commencer (statique, dynamique en fonction du login, etc), tu peux saler à différents endroits du mot de passe (début, fin, milieu, un caractère sur deux, etc), tu peux effectuer une rotation des caractères du mot de passe, etc. L'important est d'altérer le mot de passe pour qu'une personne qui renverserai le hash ne puisse trouver le mot de passe d'origine.
Si ça deviens complexe ça sera forcément dans le code. Et même en cas de piratage du binaire si t'est pas open-source et que tu a obfusqué ton code c'est pas gagné pour l'attaquant.

[Garrluk]

Alors déjà, la façon dont le sel est généré n'a aucune importance puisqu'il faut qu'il soit stocké quelque part, donc il est récupéré en même temps que le reste de ta base.
Ensuite, la façon dont tu appliques ton sel n'as aucune importance :
- soit tu es un expert en crypto et tu arrives à faire un truc qui est effectivement efficace cryptographiquement (mais dans ce cas, pourquoi t'embêter à réinventer la roue en mélangeant une fonction de cryptographie efficace combinée avec md5 plutôt que de directement utiliser une fonction efficace),
- soit tu es un dev lambda et tout ce que tu pourra faire ne rajouteras aucune sécurité à ton hash.

En fait le problème c'est que bcrypt n'est pas MIEUX que md5 : bcrypt est suffisant (car fait pour ça) et pas md5.
Bien sûr tu peux utiliser md5 et t'en sortir, ça rajoute quand même de la complexité pour cracker les mots de passes. Mais si quelqu'un de vraiment déterminé et compétent essaie de passer quand même, il y arrivera.

Pour l'histoire du binaire, même les boites de jeux qui dépensent des millions dans denuvo et compagnie n'arrive pas à protéger leur code de la décompilation plus de quelques jours.
Si tu distribue un binaire, il faut partir du principe qu'il pourra être décompilé. Compter sur le fait qu'il ne le sera pas, ça s'appelle la "sécurité par l'obscurité" et ça ne marche juste pas.
Si tu fais un service web ou autre, tu peux être un peu plus confiant dans le fait que tu arriveras à garder le code secret, mais franchement, pourquoi vouloir utiliser md5 + 1 méthode de sallage custom en espérant que le code ne se retrouve jamais dans la nature alors que tu pourrai utiliser bcrypt et t'assurer que tes mots de passes resterons chiffrés ?

[Dross]

Alors déjà, la façon dont le sel est généré n'a aucune importance puisqu'il faut qu'il soit stocké quelque part, donc il est récupéré en même temps que le reste de ta base.

Comme dit plus haut cette affirmation est fausse : rien t’empêche d'hardcoder le sel, ou de le stocker dans une autre source de données. S'il est récupéré en même temps de ta base c'est que tu a un GROS problème d'architecture.

Pour l'histoire du binaire, même les boites de jeux qui dépensent des millions dans denuvo et compagnie n'arrive pas à protéger leur code de la décompilation plus de quelques jours.
Si tu distribue un binaire, il faut partir du principe qu'il pourra être décompilé. Compter sur le fait qu'il ne le sera pas, ça s'appelle la "sécurité par l'obscurité" et ça ne marche juste pas.
Si tu fais un service web ou autre, tu peux être un peu plus confiant dans le fait que tu arriveras à garder le code secret, mais franchement, pourquoi vouloir utiliser md5 + 1 méthode de sallage custom en espérant que le code ne se retrouve jamais dans la nature alors que tu pourrai utiliser bcrypt et t'assurer que tes mots de passes resterons chiffrés ?

Denuvo c'est du DRM, rien à voir. Il existe des solutions d'obfuscations toujours non-craquées aujourd'hui (sauf par des académiciens qui savaient ce qu'ils cherchaient donc ça ne passe pas le test de la faisabilité). Pour info : je livre du code dont certaines parties sont protégées par le secret je me tiens donc particulièrement à jour de ce coté là. Mais oui 95% des obfuscateurs du marché sont pété, mais faire une petite recherche permet de trouver rapidement qui est bon et qui est mort (et c'est une veille continue évidemment).

[Garrluk]

Comme dit plus haut cette affirmation est fausse : rien t’empêche d'hardcoder le sel, ou de le stocker dans une autre source de données.

Pour moi un sel hardcodé c'est un poivre, et ça ne sert à "rien" (si par hardcoder tu veux bien dire utiliser le même sel sur toutes tes données).
En gros, ça fait seulement qu'une rainbow table générique ne peut pas permettre de craquer tes mots de passes, ce qu'offre aussi un sel.
Par contre ça n'empêche pas l'attaquant d'utiliser une rainbow table pour pouvoir craquer tous tes mots de passes en parallèles.
Et si ce n'est pas ça, désolé mais je ne vois pas de quoi tu parles.

S'il est récupéré en même temps de ta base c'est que tu a un GROS problème d'architecture.

Au contraire, aucune importance.
Un sel utilisé correctement (donc pas avec md5), n'a aucune valeur.
Bien sûr, en théorie, un attaquant qui disposerait du sel et du mdp hashé pourrait le bruteforcer, mais si tu utilises une méthode de chiffrage efficace ce n'est pas faisable en un temps humain, donc ce n'est pas un vecteur d'attaque dont tu as besoin de te méfier.

Denuvo c'est du DRM, rien à voir. Il existe des solutions d'obfuscations toujours non-craquées aujourd'hui (sauf par des académiciens qui savaient ce qu'ils cherchaient donc ça ne passe pas le test de la faisabilité). Pour info : je livre du code dont certaines parties sont protégées par le secret je me tiens donc particulièrement à jour de ce coté là. Mais oui 95% des obfuscateurs du marché sont pété, mais faire une petite recherche permet de trouver rapidement qui est bon et qui est mort (et c'est une veille continue évidemment).

Je n'ai jamais entendu parler de quoi que ce soit d'efficace, je veux bien des sources.

[Dross]

Pour moi un sel hardcodé c'est un poivre, et ça ne sert à "rien" (si par hardcoder tu veux bien dire utiliser le même sel sur toutes tes données).
En gros, ça fait seulement qu'une rainbow table générique ne peut pas permettre de craquer tes mots de passes, ce qu'offre aussi un sel.
Par contre ça n'empêche pas l'attaquant d'utiliser une rainbow table pour pouvoir craquer tous tes mots de passes en parallèles.
Et si ce n'est pas ça, désolé mais je ne vois pas de quoi tu parles.

Ça ne sert pas à rien vu que ça ne se retrouve pas dans la DB qui était ton précédent argument.

Au contraire, aucune importance.
Un sel utilisé correctement (donc pas avec md5), n'a aucune valeur.
Bien sûr, en théorie, un attaquant qui disposerait du sel et du mdp hashé pourrait le bruteforcer, mais si tu utilises une méthode de chiffrage efficace ce n'est pas faisable en un temps humain, donc ce n'est pas un vecteur d'attaque dont tu as besoin de te méfier.

Un sel est ajouté avant le hash justement pour éviter que seul le mdp soit hashé. Pour que si on le reverse on ne puisse pas avoir le mot de passe de l'usager, ce n'est pas "sans importance", si tu met les deux dans la DB et que ta stratégie de salage est évidente (genre password + sel) ça ne sert à rien on est d'accords.

Je n'ai jamais entendu parler de quoi que ce soit d'efficace, je veux bien des sources.

Tu ne va pas aimer la réponse mais je ne peux pas la donner. Surtout sur un forum public. (il n'est pas difficile de lier mon compte ici avec mon emploi).
Mais ça existe, ce sont des entreprises qui proposent ça, et comme dit, pour l'instant de nos recherches les seuls à s'être approchés du cassage de l'obfuscation sont des chercheurs qui savaient ce qu'ils cherchaient. Si vous cherchez un bon obfuscateur, cherchez les désobfuscateurs (ça se trouve facilement), puis gardez que ceux qui ne sont pas démonté de base, faites votre recherche ensuite sur le reste. Y'en a quelque uns qui résistent encore (mais ça a un coût : la perte de performance du code lui même, espérez pas mettre ça sur un jeu vidéo).

[Cheshire]

Mais le sel n'est jamais secret, il faut qu'il soit accessible par le serveur au moment de la connexion pour vérifier le mot de passe entré par l'utilisateur (en gros le serveur va vérifier que md5(mdp + sel) == mdp_bdd).
Donc si les mots de passe ont leakés, le sel se retrouve dans la nature avec le reste.
La seule protection que ça apporte c'est que ça empêche de précalculer les hash et d'en faire des rainbow tables, mais une fois que quelqu'un accède à la base il peut trouver les mots de passes sans problèmes.

Après ce que critique Kamikaze, ce n'est pas l'utilisation du sel, c'est l'utilisation de md5.
Les autres algos de chiffrages (genre bcrypt) utilisent aussi le salage

Si on part du principe que l'attaquant peut obtenir le code (le sel et la façon dont il est utilisé) en plus de la BDD, qu'est-ce que cela change d'utiliser md5 ou un autre chiffrage ?

[Garrluk]

Alors, je pars du principe que le but de hasher les mots de passes c'est pour éviter qu'un attaquant qui aurait accès à ta base de donnée (et à ton code) puisse avoir accès aux mots de passes des utilisateurs (soit pour se connecter directement à ton service, soit pour créer des bases mail/mot de passes qui pourront être vendues sur le darkweb à d'autres hackers qui s'en serviront pour hacker d'autres services).
Donc quand un utilisateur créé un compte sur ton système, au lieu de stocker le mot de passe en clair dans ta base, tu vas stocker hash(mot_de_passe).
Comme tu choisis une fonction de hash efficace (pas md5), trouver mot_de_passe à partir de hash(mot_de_passe) est impossible sans bruteforcer toutes les chaînes de caractères existantes pour retrouver la bonne.
(Pour répondre à ta question Cheschire, si tu choisi md5, tu t'arrêtes ici : l'attaquant trouve le mot de passe de ton utilisateur (ou une collision) en ~1s et tu as perdu, quelque soit le sel/poivre ou autre que tu utilises en plus).

Sauf que si on ne rajoute aucune autre contrainte, même avec une bonne fonction de hash, l'attaquant peut précalculer les hash des milliers de mots de passes les plus courant : il crée ce qu'on appelle une rainbow table.
Comme ça, au moment où il récupère une base de données, il peut juste comparer 1 à 1 tous les hash avec ceux de sa rainbow table et il a instantanément cracké tous les mots de passes qui sont dans sa table.

Pour contrer ça, la 1ère solution c'est ce qu'on appelle le poivre : on prend une valeur fixe qu'on ajoute dans le code au mot de passe avant de le hasher.
On va par exemple stocker hash(mot_de_passe + "1").
Quand un utilisateur se connecte, on va comparer cette valeur avec hash(mot_de_passe_saisie + "1").
Comme l'attaquant, dans sa rainbow table n'a calculé que hash(mot_de_passe), sa rainbow table ne lui sert à rien et il est obligé de repartir de 0.
Le problème du poivre, c'est qu'au moment où il récupère ta base (et ton code), l'attaquant peut générer une nouvelle rainbow table à partir de hash(mot_de_passe_trivial + "1"), et en 1 seule passe "attaquer" les mots de passes de tous tes utilisateurs, puisque si 2 utilisateurs ont le même mot de passe, hash(mot_de_passe_user1 + "1") et hash(mot_de_passe_user2 + "1") sont identiques donc s'il trouve une collision pour l'un, elle marche aussi pour l'autre.

Pour contrer ça, on utilise ce qu'on appelle le sel : il s'agit d'une chaîne aléatoire, en général générée à la création du compte et stocké à côté du mot de passe. Puis, au lieu de hasher uniquement le mot de passe, on hash (mot_de_passe+sel).
Cette fois, l'attaquant ne peut pas utiliser de rainbow table du tout puisque pour attaquer le compte de l'utilisateur 1, il doit générer hash(mot_de_passe_trivial + sel_utilisateur_1), ce qui ne lui servira à rien pour cracker le mot de passe d'un autre utilisateur pour lequel il aura besoin de trouver hash(mot_de_passe_utilisateur2 + sel_utilisateur_2) qui sera différent même si user1 et 2 ont le même mot de passe.
On voit donc que sel+poivre est inutile puisqu'ils règlent exactement le même problème et que le poivre n'apporte rien à un sel correctement utilisé.
Et comme il est "impossible", sans bruteforcer, de trouver mot_de_passe à partir de hash(mot_de_passe + sel), même en connaissant sel, il ne sert à rien d'essayer de le cacher.
D'ailleurs c'est pour ça que quand bcrypt retourne le hash, il retourne aussi le sel concaténé (ainsi que certaines infos sur les options utilisés pour générer le hash, comme le nombre de cycle).
Comme ça tu stock la chaine tel quel dans ta base, et quand l'utilisateur veut se connecter, tu passe le mot de passe saisie + ce que tu as stocké et bcrypt se débrouille avec ça.

Un sel est ajouté avant le hash justement pour éviter que seul le mdp soit hashé. Pour que si on le reverse on ne puisse pas avoir le mot de passe de l'usager, ce n'est pas "sans importance", si tu met les deux dans la DB et que ta stratégie de salage est évidente (genre password + sel) ça ne sert à rien on est d'accords.

Non, le sel ne sert pas à ça.
Ça c'est le boulot de ta fonction de hash. Si elle est correcte, on ne peut pas "reverse" le mot de passe, donc la question ne se pose pas.
Et si elle n'est pas bonne (au hasard, md5), alors hacher ou pas ne servira à rien car cacher ta stratégie de salage ne sert à rien : tu n'arriveras pas à la cacher de façon efficace sans réécrire une fonction de hash efficace.

Tu ne va pas aimer la réponse mais je ne peux pas la donner. Surtout sur un forum public. (il n'est pas difficile de lier mon compte ici avec mon emploi).
Mais ça existe, ce sont des entreprises qui proposent ça, et comme dit, pour l'instant de nos recherches les seuls à s'être approchés du cassage de l'obfuscation sont des chercheurs qui savaient ce qu'ils cherchaient. Si vous cherchez un bon obfuscateur, cherchez les désobfuscateurs (ça se trouve facilement), puis gardez que ceux qui ne sont pas démonté de base, faites votre recherche ensuite sur le reste. Y'en a quelque uns qui résistent encore (mais ça a un coût : la perte de performance du code lui même, espérez pas mettre ça sur un jeu vidéo).

Alors, ok, on va faire comme si cet obfuscateur magique existait (je n'ai pas les compétences pour démontrer que ce n'est pas le cas) et que tu as les moyens de l'utiliser (vu ce que tu dis c'est quand même assez particulier d'utilisation et ce n'est pas un truc qu'on va retrouver partout).

Ton code n'est quand même pas à l'abri : ta boite n'est pas à l'abri d'un piratage, à l'abris d'un employé qui ferai leaké le code (par erreur ou pas), à l'abris d'un bug ou d'un hack chez ton vendeur d'obfuscateur (ou chez n'importe lequel autre de tes fournisseurs), ...

Et de toutes façons, même si tu es sûr à 99.999% que ton code ne leakera pas, que ta "stratégie de salage" est inviolable, pourquoi utiliser une fonction de hash pourri quand l'alternative ne coûte rien et te protège mieux ?

[Dross]

Et de toutes façons, même si tu es sûr à 99.999% que ton code ne leakera pas, que ta "stratégie de salage" est inviolable, pourquoi utiliser une fonction de hash pourri quand l'alternative ne coûte rien et te protège mieux ?

Attention, je ne parle pas de défendre ni d'utiliser md5 ou sha1 ici. Je n'y connais rien en sécurité (pour nos outils on utilise des serveurs d'identité pour éviter de faire toute connerie) c'est une manière de pousser la discussion avec le peu que je connais et apprendre des trucs dans le processus.

Merci pour ta réponse complète ça me donne des pistes à creuser de mon coté.

[mathwern]

Le topic des salières

[deathdigger]

Si on part du principe que l'attaquant peut obtenir le code (le sel et la façon dont il est utilisé) en plus de la BDD, qu'est-ce que cela change d'utiliser md5 ou un autre chiffrage ?

Md5 a été "cracké". Si je ne dis pas de connerie, tu ne sais pas revenir au mot de passe initial, mais tu sais, trouver un mot qui sait générer le même résultat (et ça prend que quelques minutes).
Pour le sel, je l'imagine ainsi : à l'inscription, tu prends le mot de passe, le compte de l'utilisateur et une autre donnée fixe (par exemple le timestamp de l'inscription)+une phrase, tu mélanges tout ça via ton code et t'es pas mal (mais oui, sans utiliser md5, là-dessus on est tous d'accord). Du coup, si ta base se fait voler sans ton code, faudra un bon moment pour décrypter les mots de passe.

[gros_bidule]

Le topic des salières

Complètement ^^
Après, c'est chelou à exprimer quand tu dois justifier à qqun que les mots de passe doivent être hachés, salés poivrés. Déjà que ce sont des concepts pas évident à expliquer, mais le thème culinaire ne t'aide pas à être pris au sérieux.
Dur métier.

PS : mais votre discussion est très instructive ! Y'a des notes à prendre là, car vous expliquez bien.

[deathdigger]

Pour ceux que ça intéresse, y'a un mec qui fait des vidéos de vulgarisation assez bien foutues :
https://m.youtube.com/channel/UCMzZh0q-rcd9yDEOTXAH90g

[jilbi]

Petite maj sur ma situation: aprés un passage en SSII (qui avait l'air sympa, mais en fait la mission n'est pas ce qu'on m'a vendu) finalement j'ai mis fin à la periode d'essai. Aprés moult rebondissements, je viens de recevoir une proposition en client final, et plus proche de chez moi.
Bon, je ne sais pas ce que ça va donner, c'est une PME mais qui fait partie d'un grand compte (normalement elle est assez indépendante, il n'y a que la partie RH geré par le compte) . Mais vue que j'ai changé 3 fois de boite en un an va falloir se poser un peu là, j'ai crâmé tous mes jokers. Mais le poste est PILE ce que je cherché, du coup je vais me faire violence.

Bon, +9K par rapport à mon salaire d'avril 2020, c'est aussi un bon argument

[Shosuro Phil]

Alors, je pars du principe que le but de hasher les mots de passes c'est pour éviter qu'un attaquant qui aurait accès à ta base de donnée (et à ton code) puisse avoir accès aux mots de passes des utilisateurs (soit pour se connecter directement à ton service, soit pour créer des bases mail/mot de passes qui pourront être vendues sur le darkweb à d'autres hackers qui s'en serviront pour hacker d'autres services).

Alors je vais juste dire que la description du salage par Garrluk est exactement ce que j'en avais compris quand on m'a demandé de faire des TD de crypto en école d'ingénieurs.

Bon après, ça date de pas loin de 20 ans, je ne suis plus à jour.

[sosoran]

J'ai eu 3 entretiens avec une entreprise, demain je vais visiter les locaux pour ce qui semble être l'ultime étape. J'espère que ca passera

[jilbi]

Normalement, apres 3 entretiens et "viens visiter les locaux", t'as 90% de chances d'avoir une proposition derrière. Sauf si tu fais le con ou s'il y a un "dernier entretien avec le DG qui aurait un veto"

[sosoran]

Normalement, apres 3 entretiens et "viens visiter les locaux", t'as 90% de chances d'avoir une proposition derrière. Sauf si tu fais le con ou s'il y a un "dernier entretien avec le DG qui aurait un veto"

J'ai déjà eu l'entretien avec le supérieur du supérieur au dernier entretien, là c'est plus pour se voir en vrai. Donc je croise les doigts mais j'ai bonne espoir oui. J'espère juste pas avoir une douche froide en me rendant compte d'un truc pas abordé jusque là, mais ca devrait pas arriver à priori

[Anonyme20240202]

'Tain Sosoran va nous falloir plus de détails depuis le temps qu'on suit le feuilleton on veut les détails croustillants

[gros_bidule]

La visite des bureaux, tant que tu ne te manges pas une porte façon Takeshi's Castle, c'est tout bon .
A la limite, c'est plutôt toi qui pourrais éventuellement donner un avis négatif, si tu vois qqchose qui te choque (mais ça serait vraiment LE gros coup de pas de bol). N'hésite pas à demander à passer 10min avec un futur collègue pour prendre la température, connaître sa journée type par ex, et pourquoi selon lui tu devrais te plaire ici (ou ce qui lui plaît à lui). C'est tjrs sympa, et tu peux avoir de bonnes surprises.
En tous cas c'est cool !

[Aigle4]

+1
La, si je te faisais faire la visite rapide, je scruterai tes faits et gestes et j'attendrais un minimum de questions (logistiques on va dire).
A toi de voir comment tu "sens" le site, voire les gens.
Avec l'experience, tu me jettes sur un plateau d'une boite d'Oil and Gas, et a l'oeil je te donne les Ingenieurs Process, les producteurs, le service Compta et Informatique sans me louper