Connexion

[Argorate]

Moué, enfin mettre son grain de sel dans la table est complètement anti-sécure a mon sens, même s'il ne connais effectivement pas l'algorithme et donc la position du "salt", il a le mdp + le salt, il a juste a faire une boucle pour tester toutes les positions possible pour le salt... Je trouve ça middle, après ton algorithme peut être plus compliqué c'est vrai, mais dans ce cas pas besoin de s'embêter a enregistrer le grain de sel.
M'enfin, chacun gère ça un peu comme il veux, tant que c'est difficile a résoudre^^

PS: Viciousity : epic fail ;

function encrypt(string1,string2){

  return md5($string1.'::'.$string2); //version clarifié

}

private

  def encrypt string1, string2

    require 'digest'

    Digest::SHA256.hexdigest("#{string1}::#{string2}")

  end

Oui... oui... ruby est vachement plus clair, j'avoue... (ou pas ^^)

Sans parler de la remarque pertinente de Ter Rowan

[Sephi-Chan]

Le salt étant différent pour chaque personne, il faudra quelques années pour obtenir la bonne combinaison pour une personne.
Alors que si tu as un salt unique codé en dur dans ton application, c'est moins sécurisé.

Argorate, en l'occurrence, c'est plutôt un fail de PHP, qui a des fonctions md5() ou sha1() mais pas de sha256() ! Quelle honte. Chez nous c'est cohérent.

Et puis le require n'a rien à faire là…


Sephi-Chan

[Viciousity]

Non normalement le require se met avant le chargement de la classe mais dans le cas qui nous occupait je l'ai groupé dans la fonction pour qu'on comprenne d'ou sortait le Digest::SHA256 ;P

[Holy]

Y a moyen de virer toujours au duel PHPvsRoR ?!

Sans déconner, même pour des trucs qui ont rien à voir, on en revient à ça. Alors oui, c'était une mini joke, un p'tit truc de rien du tout, et on retombe sur un "Quelle honte. Chez nous c'est cohérent ". Je trouve que ça devient vraiment GAVANT. Merde quoi. Je vise personne en particulier, mais ça commence à me blaser sévère de toujours retomber sur ce genre de propos exclusifs. On est là pour parler de sécurité, de jeux web, de créativité, d'outils, pas pour rabâcher toujours les mêmes conneries. Ouvrez un sujet spécial défouloir ou baston des langages si vous avez besoin de montrer vos muscles programmatiques. Sincèrement, j'apprécie énormément Jeuweb qui m'a apporté plus que n'importe quel autre forum et/ou site du même genre, mais là ça devient carrément pénible.

[Sephi-Chan]

Tu noteras que des gens ont choisi de troller l'exemple donné par Viciousity.
Il fallait donc s'attendre à une réponse de ce style. Mais je compte bien masquer les messages, moi aussi ça m'agace.


Sephi-Chan

[Viciousity]

Ben je pense pareil ^^

j'avais bien mis Joke pour ne pas qu'on tombe dans la polémique, j'ai essayé de donner une méthode en procédural PHP pour que les gens comprennent ce que je voulais dire par salt et c'est vrai que sa a encore dégénérer
De plus je n'ai nullement attaquer l'intégrité de PHP (qui pour moi est un très bon langage ...) mais seulement essayer de donner un exemple d'implémentation.

Alors désolé pour ceux qui ont mal pris ma mini-joke

Fin soit Débat PHPvsRUBY closed

Et si quelqu'un est interessé je veux bien faire un tutorial plus clair sur cette méthode mais il me faudrait un correcteur/optimisateur de code parce que le PHP c'est pas le truc que je surgère

[niahoo]

bah je peux te le corriger si tu veux.

"""Le salt étant différent pour chaque personne, il faudra quelques années pour obtenir la bonne combinaison pour une personne.
Alors que si tu as un salt unique codé en dur dans ton application, c'est moins sécurisé."""

Ben il faudra surtout 1 seconde puisque le salt est dans la table. donc le mec l'a.

Fin bon, je dois passer à côté d'un truc...

edit: hmm par contre ce que je comprends c'est que ça l'empêche de trouver la méthode de hashage (notre fonction encrypt) et là c'est efficace en effet.

[Sephi-Chan]

Si tu utilises une salt commun pour tout le monde, le pirate n'aura qu'à générer des rainbow table pour différentes compositions d'emprunte : une rainbow pour la version password + salt, une pour la version password + salt, une pour la version password + salt + "18/08/1989", etc. C'est infiniment long tant il y a de possibilités de mot de passes et tout autant de composition de mot de passe.

Avec un salt par utilisateur, tu imposes au pirate de regénérer tout ça pour… Chaque utilisateur ! C'est encore moins viable : le bruteforce sera plus efficace.


Sephi-Chan

[Viciousity]

Ben en fait la base réelle du salt est de perdre l'information importante.
Du coup, quand tu considères la fonction encrypt, on pourrait la définir comme encrypt(information_importante,salt)
En gros, ce que retourne la fonction dépend de deux facteurs et l'on doit donc les avoir tous les deux pour pouvoir isoler l'information importante.
Et pour le peu que tu utilises un truc un peu violent comme HASH genre SHA-256 ou SHA-512(si t'es parano), l'information importante ne peut être retrouvé rien qu'en retrouvant les DEUX données initiales (ce que le hacker recherche et la il est le serpent qui se mord la queue)

En plus utilisant un facteur aléatoire, il n'y a aucune logique pour "forcer" la chaine