Reprise du message précédent :

J'insiste aussi : dans une boîte où l'admin système n'a pas à connaître les infos de chaque user, il est normal qu'il n'ait pas accès au password.
Et si la BDD se fait cracker soit par oubli de patch, soit par utilisation éclair d'un exploit rendu public quelques jours avant avant tout patch de sécu sur ta BDD ? Bin le hacker récolte les pass de tous les users et fait ce qu'il veut derrière

franchement si un hacker arrive jusqu'à la BDD, il a 9/10 d'avoir le même password pour le FTP c'est achement plus rigolo de bousiller tout le site, que de hacker un compte mail à 2 balles...

 
Quand tu perds ton mot de passe, on t'en renvoie un généré aléaroirement, c'est rarement en clair.

 
Bon Ok il aura un mdp hashé dans ce cas. Ben c'est pas grave hein ! Après tout, c'est çà qu'il attend le seveur non    
 
Heu, bon alors, à quoi çà sert ?
 
Tout simplement à se masturber le cerveau, et a faire croire à une certaine sécurité !
 

Pour le hacker crétin, oui. Pour le fraudeur qui veut accéder aux infos, non

 
on utilise generalement du javascript pour le md5 histoire de na pas faire trainer le mdp en claire sur le reseau.

Et si le client a pas le JS activé... Comment on fait la différence ?

 mais c'est déjà plus chiant, il faut simuler un post au serveur avec l'envoie du md5. OK, je l'avoue, c'est pas bien compliqué   .
 
 
 
c'est pourquoi la methode d'envoie de clé privée (comme tu l'a decris) est une methode plus aboutie a mon sens.

 
enfin, c'est ecrit dans les specs que js doit etre activé

P'têt à ce que justement l'admin ou qui que ce soit ne puisse pas l'intercepter en clair ?

Bon j'ai 2 arguments pour le moment :
 
1- Parce que les utilisateurs utilise le même MDP partout.
2- Parce que si un Malveillant à réussi à les lire, il peut s'enservir frauduleusement plus tard une fois que la faille est refermé. (Ben oui, si la faille est toujours là...)
 
Conclusion :
Re 1- Ne pas laisser le choix du mot de passe à l'utilisateur.
Re 2- Re-générer des mots de passes régulièrement et en particulier en cas de soupçon d'intrusion ou après avoir bouché une faille.
 
Ca me semble plus solide comme çà non ?

Vi alors effectivement, c'est un choix. Mais en imaginant que ce concept soit implémenté un peu partout, chaque utilisateur d'Internet va se retrouver avec 10 pass différents et impossibles à mémoriser
Y a un moment où il faut trouver le juste milieu entre sécurité et convivialité et c'est ce que le cryptage du pass avec un algo non réversible me semble apporter.

 
Ouais... Javascript... Et ca tient par quel morceau de ficelle ?    

 
la Foi  

 
juste milieu entre sécurité et convivialité = Illusion de sécurité.

Bien sûr mais le tout sécuritaire est aussi une illusion en informatique. Je sais pas comment ça marche dans ta boîte mais ici, si je propose une solution de login à base de password généré aléatoirement, on va me rire au nez et dans le cas contraire, on aura un client qui s'en plaindra

 
c'est sur ! mais ce n'est demain la veille ! mais trop de sécurité tue l'utilisation du produit : si la sécurité est trop contraignante, les users n'adhèreront pas et risquent de ne pas utiliser le produit. il faut "eduquer" les users  
 
EDIT: encore grillaid !

Dans ma boîte, le mot de passe d'accès à notre intranet DOIT être changé régulièrement par l'utilisateur.
Si t'as un client mécontent, tu lui laisse la possibilité de définir lui-même le mot de passe tout en lui signalant que la sécurité de ses données devient alors très faible.
 
Je me souvient d'une pub pour une banque qui propose à ses clients de choisir leur code de Carte Bleue. Dans la pub l'utilisateur témoin est la ménagère standard, qui arrivée à la caisse, réfléchie 2 secondes, puis se souvient qu'il est "caché" dans le tatouage de son chien...
 
Mais que de connerie !
Dans le contrat, il est bien stipulé que ce code ne doit être écrit nulle part !
 
A quand la CB conviviale pour amnésiques, CAD : sans code ?

Euh, login/pass est tout de meme le niveau de securisation le plus faible et de loin... Donc de la a parler de securité par l/p  

Bin idem pour le site pour amnésiques qui rappelle le pass oublié ou perdu
Et concrètement, tu ferais comment si tout sur le Web marchait comme ça ? Sans exagérer, je dois bien avoir une dizaine de comptes sur le Net. J'imagine même pas l'horreur si je devais avoir autant de pass générés d'au moins 8 caractères du style hBy6F2pm. Et là aussi, écrire les pass sur un bout de papier n'est pas recommandé, donc tu fais comment ?
Pour une CB, c'est 4 chiffres à retenir pour une seule chose (t'as rarement 10 CB différentes) donc je comprends que ça soit fixé par la banque. Mais pour les pass, je trouve ça totalement inconcevable

On est d'accord !
 
Tout ce que je dis, c'est que stocker le MD5 d'un MDP, çà revient à changer un P en 5

Un petit lien sur la sécurité :
 
http://www.nexen.net/interview/index.php?id=30
 
Ca parle des trous de sécu les plus courrant dans les applis WEB.
 
Je n'ai pas lu qu'il fallait coder les mots de passe des utilisateurs Un oubli peut-être...

 
et la "8" çà ne rentre pas dans ce domaine ?  

Ca doit être un oubli, effectivement, puisqu'ils ne mentionnent même pas la notion de droits sur des objets ou sur des parties du site...
Plaisanterie à part, le document auquel tu fais référence s'intitule "PHP et le TOP 10 des trous de sécurité", donc ce n'est a priori pas une liste exhaustive

Ton raisonnement n'est pas bon. Donne moi le hash MD5 d'une chaine alphanumérique de 4 caractères et je te la retrouve en quelques secondes (compte quelques secondes de plus pour 5 caractères, quelques minutes pour 6 ... quelques jours pour 7, sur un Céléron 900).

 
a toi de jouer :
 

Quel intérêt si on utilise pas le même salt ?

 
Il s'agit de "test"

Je ne connais pas ce terme. Tu veux parler du fait que des chaines différentes peuvent avoir un hash MD5 différent ?

JavaScript pour la sécurité ?
 
Use SSL Luke

Non, que la même chaîne puisse avoir deux hashages différents selon une variable introduite au moment du cryptage ; j'en parle plus haut : http://forum.hardware.fr/forum2.ph [...] t=#t416006

 
le truc c'est que tout le monde fait comme moi, et utilise le hashage avec un salt par defaut.  

Oui mais bon, si on rajouter le salt dans le code php, ça n'avance à pas grand chose, enfin faudra lire le code . Enfin, moi je le code uniquement pour des raisons personelles de ne pas savoir le voir comme ça.. Puis si l'utilisateur rentre 40 caractères je saurai pas le retrouver