Bonjour,
> Je viens de faire quelques tests d'utilisation de mots de passe comprenant des accents sur deux sites situés sur deux serveurs différents ... Visiblement, il doit y avoir un souci quelque part ( moi, spip, mes serveurs ? ^^ ) car je peux rentrer un mot de passe accentué ( depuis l'interface d'administration, ou depuis le formulaire d'oubli de mot de passe ), mais je ne peux pas m'authentifier avec ...
...
Quelle version de SPIP ?
Quelle configuration de charset sur le serveur ? ...
Car il va sans dire que chez moi ça marche (c)
mais ce n'était pas le cas en 2.1.0 en effet.
Cela dit il peut rester un cas foireux quelque part.
Mais il faudrait plus d'info, voir un accès au site qui merde pour comprendre quel cas bug.
Cédric
2011/3/8 cedric.morin@yterium.com <cedric.morin@yterium.com>
Quelle version de SPIP ?
Quelle configuration de charset sur le serveur ? …
Car il va sans dire que chez moi ça marche (c)
mais ce n’était pas le cas en 2.1.0 en effet.
Cela dit il peut rester un cas foireux quelque part.
Mais il faudrait plus d’info, voir un accès au site qui merde pour comprendre quel cas bug.Cédric
Je viens de tester 2.1.8 vierge par spip_loader et une 2.3-dev : idem, les accents empêchent de m’identifier. UTF-8 de partout ?
Je t’envoie un accès en privé au besoin.
Est-ce que tu aurais le Suhosin plugin sur ton install (car il definit sa fonction sha256 côté PHP) ?
Quelle version de PHP utilises-tu ?
J’ai repris les tests et j’ai bien
Côté PHP :
sha256('e') = '3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea'
sha256('é') = '63e3c807f93f669a2625f37ee673726c36ef3e99b6b7db02c910be25087e0f9c'
Ce qui correspond aux résultats obtenus côté JS.
La difficulté réside bien dans le traitement des caractères UTF.
A ce titre, la proposition de repasser en iso par un utf8_dcode n’est pas acceptable car elle interdira de facto de mots de passes non convertible en iso.
La valeur
de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
pour ‹ é › correspond a priori a un hash calculé sur une chaine iso et non utf8.
Est-ce que tu peux regarder ce que ça donne chez toi ?
2011/3/9 cedric.morin@yterium.com <cedric.morin@yterium.com>
Est-ce que tu aurais le Suhosin plugin sur ton install (car il definit sa fonction sha256 côté PHP) ?
Quelle version de PHP utilises-tu ?J’ai repris les tests et j’ai bien
Côté PHP :
sha256('e') = '3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea'
sha256('é') = '63e3c807f93f669a2625f37ee673726c36ef3e99b6b7db02c910be25087e0f9c'Ce qui correspond aux résultats obtenus côté JS.
La difficulté réside bien dans le traitement des caractères UTF.A ce titre, la proposition de repasser en iso par un utf8_dcode n’est pas acceptable car elle interdira de facto de mots de passes non convertible en iso.
La valeur
de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
pour ‹ é › correspond a priori a un hash calculé sur une chaine iso et non utf8.
Est-ce que tu peux regarder ce que ça donne chez toi ?
Bonjour, désolé pour le retard.
Version de php 5.3.5-0.dotdeb.0.
Alors oui, y a bien Sushosin dans phpinfo (Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.32.1), et sha256(‹ é ›) donne bien cette chaine :
de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
Ca vient de la config de l’hébergeur du coup ?
2011/3/9 cedric.morin@yterium.com <cedric.morin@yterium.com>
Est-ce que tu aurais le Suhosin plugin sur ton install (car il definit sa fonction sha256 côté PHP) ?
Quelle version de PHP utilises-tu ?J’ai repris les tests et j’ai bien
Côté PHP :
sha256('e') = '3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea'
sha256('é') = '63e3c807f93f669a2625f37ee673726c36ef3e99b6b7db02c910be25087e0f9c'Ce qui correspond aux résultats obtenus côté JS.
La difficulté réside bien dans le traitement des caractères UTF.A ce titre, la proposition de repasser en iso par un utf8_dcode n’est pas acceptable car elle interdira de facto de mots de passes non convertible en iso.
La valeur
de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
pour ‹ é › correspond a priori a un hash calculé sur une chaine iso et non utf8.
Est-ce que tu peux regarder ce que ça donne chez toi ?Bonjour, désolé pour le retard.
Version de php 5.3.5-0.dotdeb.0.
Alors oui, y a bien Sushosin dans phpinfo (Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.32.1), et sha256(‹ é ›) donne bien cette chaine :
de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
Du coup tu dois avoir une fonction
_nano_sha256
definie par auth/sha.256.inc.php
Peux tu checker la valeur
_nano_sha256(‹ é ›)
?
Ca vient de la config de l’hébergeur du coup ?
Oui et non. Le patch sushosin fournit en effet une fonction sha256, et du coup on tombe sur elle au lieu de celle de auth/sha256.inc.php
Mais le problème vient de la largeur qu’on choisit pour decomposer la chaine en caractères.
Selon qu’on prenne 8 ou 16 bits on a pas le même résultat.
Actuellement les fonctions de auth/sha256.inc.php et de prive/javascript/sha256.js utilisent par defaut une largeur de 8bit pour décomposer la chaine,
sauf si un caractère étendu (ie sur plus de 8bits) est rencontré, auquel cas la largeur d’un caractère pris en compte est 16bits.
Donc dans toutes les methodes, le sha d’un ascii non étendu est le même.
Mais sinon il y a visiblement des divergences. L’important pour nous étant que l’on utilise la même méthode côté PHP et côté JS.
Pour compléter la fête :
hash(« sha256 », ‹ é ›, false) donne
4a99557e4033c3539de2eb65472017cad5f9557f7a0625a09f1c3f6e2ba69c4c
ce qui est encore différent 
Si tu me confirme _nano_sha256(‹ é ›)
alors je pense qu’il suffit simplement de nommer la fonction sha256 autrement pour ne pas retomber sur celle de sushosin quand le patch est présent.
Cédric
Bonjour,
tout comme Guy, j'ai Sushosin sur mon serveur ( configuration de base debian ).
J'ai tenté de vérifier la valeur de :
_nano_sha256('é');
Et ...
Fatal error: Allowed memory size of 1 073 741 824 bytes exhausted (tried to allocate 20 bytes) in xxxxxx/ecrire/auth/sha256.inc.php on line 171
Call Stack
# Time Memory Function Location
1 0.2424 330984 {main}( ) ../test.php:0
2 0.3210 337232 _nano_sha256( ) ../test.php:32
3 0.3379 337784 nanoSha2->hash( ) ../sha256.inc.php:424
4 0.3380 344872 nanoSha2->string2binint( ) ../sha256.inc.php:278
5 0.3380 345080 nanoSha2->string2ordUTF8( ) ../sha256.inc.php:200
6 577.5369 1073494900 nanoSha2->ordUTF8( ) ../sha256.inc.php:153
2011/3/9 Guy Cesaro <guy.cesaro@gmail.com>
Version de php 5.3.5-0.dotdeb.0.
Alors oui, y a bien Sushosin dans phpinfo
Comme toujours sur les serveurs Debian. Le patch est livré de série, visiblement , dès que tu installes l’artillerie LAMP. Je ne saurais plus dire, en revanche, à quel moment précis il arrive dans l’équation…
2011/3/9 Vincent <vincent@logaweb.fr>
Bonjour,
tout comme Guy, j’ai Sushosin sur mon serveur ( configuration de base debian ).
J’ai tenté de vérifier la valeur de :
_nano_sha256(‹ é ›);Et …
Fatal error: Allowed memory size of 1 073 741 824 bytes exhausted (tried to allocate 20 bytes) in xxxxxx/ecrire/auth/sha256.inc.php on line 171
Call StackTime Memory Function Location
1 0.2424 330984 {main}( ) …/test.php:0
2 0.3210 337232 _nano_sha256( ) …/test.php:32
3 0.3379 337784 nanoSha2->hash( ) …/sha256.inc.php:424
4 0.3380 344872 nanoSha2->string2binint( ) …/sha256.inc.php:278
5 0.3380 345080 nanoSha2->string2ordUTF8( ) …/sha256.inc.php:200
6 577.5369 1073494900 nanoSha2->ordUTF8( ) …/sha256.inc.php:153
Même soucis, on doit s’y prendre mal ?
Du coup, je t’ai envoyé de quoi tester l’hébergement sur ton mail, Cédric, lorsque tu auras le temps…
Ah oui j’ai vu ça hier, ça le fait quand on envoie un « é » en isotruc dans la fonction
(mais pas si le « é » est en UTF8)
Visiblement c’est le ord() qui se vautre mais je ne sais pas pourquoi…
Je viens de faire un test un peu stupide, mais dans le doute ...
J'ai collé un
echo $h." - ".$index." - ".$len; die();
que j'ai baladé un peu partout dans la fonction ordUTF8.
Il me sort "233 - 0 - 1" donc le ord renvoie bien 233, ce qui semble logique. par contre $index est à 0, et len à 1.
Du coup, ça ne peut pas rentrer dans
else if ($h <= 0xEF && $index < $len - 2)
( $h valant 233 0xE9 mais $index = 0 et $len - 2 = 1-2 = -1 )
Du coup, au final, elle doit renvoyer false, ce qui flanque peut être le bazar un cran plus haut ( genre dans la while de string2ordUTF8 ) ?
Bon, je confirme, ce serait bien entre string2ordUTF8 et ordUTF8 que le problème se situerait.
En effet, quand string2ordUTF8 reçoit "é" dans $s , elle rentre dans le while avec $i = 0 et strlen($s) = 1.
La farce, c'est que $this->ordUTF8($s, $i, $bytes); renvoie false et $bytes vaut 0 ...
D'où la boucle infinie.
En utf8, "é" vaut bien 0xE9 ? J'avoue que je nage un peu, voir même beaucoup sur les encodages de caractères ...
En utf8, "é" vaut bien 0xE9 ?
non, ça c'est sa valeur en iso-latin : 0xe9 = 233
en utf8 ce caractère s'encode sur deux octets : 195 169 (0xc3 0xa9)
J'avoue que je nage un peu, voir même beaucoup
sur les encodages de caractères ...
des explications toujours valables ici http://www.uzine.net/article1785.html
-- Fil
Bon, j'ai continué mes bidouilles...
J'ai modifié la fonction string2ordUTF8($s,&$byteSize) de sha256.inc.php comme suit :
function _convert($content) {
if(!mb_check_encoding($content, 'UTF-8') OR !($content === mb_convert_encoding(mb_convert_encoding($content, 'UTF-32', 'UTF-8' ), 'UTF-8', 'UTF-32'))) {
$content = mb_convert_encoding($content, 'UTF-8');
}
return $content;
}
function string2ordUTF8($s,&$byteSize){
// pour avoir toujours de l'utf-8
$s = $this->_convert($s);
Ainsi, j'évite le problème de boucle infinie dû au latin-1.
sha256 : de2e331d891ae267a7009cb45b4e8830f170e0c937288ea2731a1941c7a53b0d
_nano_sha256 : 63e3c807f93f669a2625f37ee673726c36ef3e99b6b7db02c910be25087e0f9c
Donc, effectivement, en employant toujours _nano_sha256, je suppose que ça devrait coller !
des explications toujours valables ici http://www.uzine.net/article1785.html
Un peu tard ( mon mail est resté à l'état de brouillon, j'ai oublié de l'envoyer ... ) mais merci pour l'information !
http://core.spip.org/projects/spip/repository/revisions/17351
devrait corriger le problème.
Cédric
Je vais répercuter ça à l'identique sur mon code et en profiter pour avancer. Merci !