SQLite ou pas SQLite, that is ze question !

Par Franck, . Lien permanent Dotclear

J’en cause ici parce que j’ai l’impression que ce blog est assez lu par ceux qui geekent autour et avec Dotclear et donc voilà la question que je me pose en ce moment.

Vous n’êtes pas sans savoir que la mise à jour de la structure de la base n’est pas assurée pour ceux qui utilisent QSLite comme système de stockage des données. J’ai un peu regardé la littérature à ce sujet, et à part produire pas mal de code pour gérer ça au mieux, il n’y a pas grand chose de simple, ne serait-ce que pour changer la longueur d’un champ dans une table[1].

Or, avec l’idée de renforcer la sécurité des mots de passe stockés dans la base, j’aimerais pouvoir permettre l’usage d’autres algorithmes que les seuls sha1 et md5. Seulement l’usage de certains algorithmes supportés par PHP produit un chiffrement dont la longueur peut être supérieure aux actuels 40 caractères actuellement prévus dans la base[2].

Par exemple, les algorithmes sha512 ou whirlpool produisent un résultat de 128 caractères de long. Au passage, voilà comment afficher la liste des algorithmes supportés par votre installation et les longueurs résultantes :

$algos = hash_algos();
foreach ($algos as $algo) {
	$code = crypt::hmac(DC_MASTER_KEY,'mot de passe',$algo);
	echo '- '.$algo.' → '.strlen($code).'<br />';
}

Ce qui donne, sur mon installation locale en PHP7, le résultat suivant :

md2 → 32
md4 → 32
md5 → 32
sha1 → 40
sha224 → 56
sha256 → 64
sha384 → 96
sha512 → 128
ripemd128 → 32
ripemd160 → 40
ripemd256 → 64
ripemd320 → 80
whirlpool → 128
tiger128,3 → 32
tiger160,3 → 40
tiger192,3 → 48
tiger128,4 → 32
tiger160,4 → 40
tiger192,4 → 48
snefru → 64
snefru256 → 64
gost → 64
gost-crypto → 64
adler32 → 8
crc32 → 8
crc32b → 8
fnv132 → 8
fnv1a32 → 8
fnv164 → 16
fnv1a64 → 16
joaat → 8
haval128,3 → 32
haval160,3 → 40
haval192,3 → 48
haval224,3 → 56
haval256,3 → 64
haval128,4 → 32
haval160,4 → 40
haval192,4 → 48
haval224,4 → 56
haval256,4 → 64
haval128,5 → 32
haval160,5 → 40
haval192,5 → 48
haval224,5 → 56
haval256,5 → 64

J’ai fait les modifications nécessaires côté Clearbricks pour permettre l’utilisation d’un autre algorithme, maintenant je suis devant le choix suivant pour continuer côté Dotclear :

  1. Je ne touche à rien côté longueur du champ qui stocke le mot de passe et je me limite aux 40 premiers caractères du mot de passe chiffré fourni par Clearbricks. L’avantage est que ça ne change pas côté structure de la base, par contre ça réduit forcément la sécurité.
  2. J’agrandis le champ à 255 caractères, histoire de voir venir, mais je force les utilisateurs de SQLite à mettre à jour de manière fastidieuse leurs installations.

Pour résumer, est-ce que ça vaut le coup de ne pas toucher à la structure et permettre une mise à jour « douce », ou est-ce que l’usage de SQLite est suffisamment anecdotique pour passer outre, ou s’il ne l’est pas [anecdotique], développer ce qu’il faut pour assurer quoi qu’il arrive une mise à jour automatique des bases SQLite ?

Autre interrogation :

Sachant que l’algorithme qui a servi à chiffrer le mot de passe n’est pas stocké dans la base, et heureusement d’ailleurs, il est compliqué de mettre en place un système automatique de conversion du chiffrement de l’ancien au nouveau si celui-ci est modifié dans la configuration.

On sera quoi qu’il en soit obligé de passer par la procédure de récupération de mot de passe pour pouvoir l’appliquer et se connecter ensuite.

Du coup, est-ce que renforcer la sécurité pour la prochaine version 2.10 de Dotclear vaut réellement que j’y passe un peu de temps ? J’aurais tendance à dire que oui, mais je ne suis pas (encore) le seul utilisateur de Dotclear sur la planète.

Bref, j’ai pensé que la première étape était d’essayer de recenser les utilisateurs actuels de SQLite sur cette planète, sachant que les blogs des différentes plateformes comme Free ou Gandi sont sur PostgreSQL (ou peut-être sur MySQL pour les plus petites d’entre elles) :

Je vois que j’ai déjà quelques réponses[3] à mon enquête, c’est cool \o/

Maintenant vous pouvez aussi me répondre dans les commentaires de ce billet si vous préférez !

Notes

[1] À part renommer une table ou ajouter un champ à une table, la commande ALTER TABLE de SQLite ne permet rien.

[2] L’algorithme md5 produit un résultat de 32 caractères de long, sha1 en produit un qui fait 40.

[3] À l’heure où j’écris ce billet, 4 utilisent MySQL, 2 PostgreSQL et 2 ne savent pas, et s’ils ne savent pas je pense que je peux raisonnablement estimer qu’ils n’utilisent pas SQLite qui est un peu plus particulier.

Ajouter un commentaire

Les champs suivis d'un * sont obligatoires

Les commentaires peuvent être formatés en utilisant la syntaxe Markdown Extra.

Ajouter un rétrolien

URL de rétrolien : https://open-time.net/trackback/12794

Haut de page