rub a écrit:
Le A partiel, c'est possible. C'est à dire utilisation du sha1 sans laissant la colonne (inutile) pour l'instant?
Bien sûr que c'est possible. Le seul truc que je veux à tout prix éviter, c'est les changements de structure de base dont on peut se dispenser. Un changement de base, ça signifie une complexité du processus de fabrication de release multiplié par 5 et donc je suis beaucoup plus frileux pour la faire la release. Une release sans changement de base, c'est tranquille, ça se fait rapidement et sans flipper.
Hors ligne
Je comprends parfaitement le point de vue de z0rglub, et je crois qu'il faut souscrire à cette règle et ne plus y déroger.
8-)
Hors ligne
VDigital a écrit:
Je comprends parfaitement le point de vue de z0rglub, et je crois qu'il faut souscrire à cette règle et ne plus y déroger.
8-)
Je pensais que c'était déjà le cas.... ;-)
Et pis, je la remballe ma page wiki ou pas?
Hors ligne
Garde ta page de Wiki, les idées sur l'historique et les tris ne sont que les prémices de l'usage des sessions.
8-)
Hors ligne
Voila c'est fait:
B. fini #users.auto_login_key trunk svn 1622
C. une session est cree meme pour les visiteurs; l'ordre des miniatures est sauve maintenant dans la session trunk svn 1623
Dernière modification par rvelices (2006-12-01 02:41:27)
Hors ligne
rvelices a écrit:
Voila c'est fait
Excellent. Me voilà réconcilié avec les sessions standard :-) Merci rvelices
Hors ligne
Petit "truc" qui me dérange un peu : la fonction sha1 n'est disponible que depuis PHP 4.3. Bon OK, elle date de décembre 2002, donc normalement c'est présent partout maintenant. Je laisse ici la remarque que les développeurs sache que cette fonction n'est pas "ancestrale".
Hors ligne
Il suffirais de rajouter un contrôle, si la fonction est dispo c'est en sha1 dans le cas contraire c'est en md5. C'est ce que j'ai eu fais pour coupler Pwg avec PunBB qui utilise le même fonctionnement.
Hors ligne
z0rglub a écrit:
Petit "truc" qui me dérange un peu : la fonction sha1 n'est disponible que depuis PHP 4.3. Bon OK, elle date de décembre 2002, donc normalement c'est présent partout maintenant. Je laisse ici la remarque que les développeurs sache que cette fonction n'est pas "ancestrale".
Facile a changer. Mais j'ai bien peur qu'on a deja utilise d'autres fonctions php 4.3 d'une maniere involontaire jusqu'a maintenant. J'ai pas un exemple precis mais c'est fort probable.
Hors ligne
Laissons comme ça pour le moment, on traitera au cas par cas lorsque des problèmes nous seront rapportés.
Hors ligne
flipflip a écrit:
Il suffirais de rajouter un contrôle, si la fonction est dispo c'est en sha1 dans le cas contraire c'est en md5. C'est ce que j'ai eu fais pour coupler Pwg avec PunBB qui utilise le même fonctionnement.
Oui, je connais bien ce bout de code de punbb, c'est d'ailleurs pour cela que je sais que sha1 n'est pas une vieille fonction dans PHP :-)
Hors ligne
Désolé d'avoir tardé à intervenir je suis un peu débordé en ce moment.
Je vois que vous avez avancer si j'ose dire. Je dirais plutôt reculer. Quoi qu'il en soit c'est fait. :-(
Je suis conscient que le code sur les sessions n'était pas parfait mais les remontées d'informations ou de problèmes rencontrés étaient loin d'être parfaits. Mais dans les quelques environnement que j'ai, je n'ai pas rencontré de problèmes majeurs.
Ce qui me gêne le plus dans la façon dont rvelices a réglé le problème est le fait de mettre le mot de passe dans la clé d'auto-connexion (même s'il est crypté). Lisez n'importe quel article sur la sécurité et vous verrez que c'est du grand n'importe quoi. Si la clé d'auto-login est compromise, le compte est compromis. Ce n'est certes pas un compte bancaire que l'on protège mais certains utilisent pwg professionnellement et vendent les photos. Pourquoi dans ce cas ne pas mettre deux cookies: un pour le login et l'autre pour le mot de passe ? C'est du pareil au même!
Hors ligne
Pour "voler" le mot de passe d'un admin, il faut:
1. s'infiltrer sur son ordinateur et lui piquer son cookie
2. disposer d'un cluster de 10,000 supercalculateurs pour trouver le mot de passe en clair à partir du mot de passe chiffré. En théorie, le SHA1 nécessite 2^69 (590,295,810,358,705,651,712) itérations pour le décrypter.
J'estime que le trou de sécurité n'est pas si béant :-) et maitenant surtout, le code et le principe sont plus simple et donc davantage maintenable et moins potentiellement buggué.
Hors ligne
z0rglub a écrit:
Pour "voler" le mot de passe d'un admin, il faut:
1. s'infiltrer sur son ordinateur et lui piquer son cookie
Oui ou passer après lui et récupérer son cookie.
z0rglub a écrit:
2. disposer d'un cluster de 10,000 supercalculateurs pour trouver le mot de passe en clair à partir du mot de passe chiffré. En théorie, le SHA1 nécessite 2^69 (590,295,810,358,705,651,712) itérations pour le décrypter.
En force brute ok mais avec un dictionnaire c'est nettement plus facile.
z0rglub a écrit:
J'estime que le trou de sécurité n'est pas si béant :-) et maitenant surtout, le code et le principe sont plus simple et donc davantage maintenable et moins potentiellement buggué.
Je ne fais que donner mon avis. J'estime que c'est une très mauvaise idée. Après si vous tenez absolument à l'implémenter de cette façon, tant pis. Je ferais un patch sur ma galerie.
Hors ligne
nicolas a écrit:
z0rglub a écrit:
2. disposer d'un cluster de 10,000 supercalculateurs pour trouver le mot de passe en clair à partir du mot de passe chiffré. En théorie, le SHA1 nécessite 2^69 (590,295,810,358,705,651,712) itérations pour le décrypter.
En force brute ok mais avec un dictionnaire c'est nettement plus facile.
Je n'ai pas spécialement compris la méthode, mais c'est la meilleure à l'heure actuelle qui permet d'obtenir 2^69, voir SHA1 sur Wikipedia.
Hors ligne