MySQL et Java: le tableau d'octets n'est pas le même lorsqu'il est récupéré qu'il l'était lors du stockage


vedi0boy

Je crée une table pour les utilisateurs contenant leurs mots de passe hachés et c'est du sel.

Le problème est que lorsque je crée la ligne de l'utilisateur dans la table et que je sauvegarde le sel et le mot de passe (les deux sont byte[]stockés dans des VARBINARYcolonnes) et que j'essaie de récupérer ces données lorsque l'utilisateur se reconnecte, le sel retourné et le mot de passe haché sont différents de lui. était quand j'ai créé la ligne.

Pour obtenir les données que j'utilise ResultSetet que j'appelleresultSet.getBytes("password")

Pour créer la ligne, j'utilise une requête comme celle-ci (suppression des autres données de colonne pour le rendre plus simple):

String query = String.format("insert into users (`password`, `salt`) values ('%s','%s');", user.getHashedPassword(), user.getSalt());

Peut-il y avoir une conversion ou quelque chose qui se produit qui cause ce problème? Dois-je utiliser autre chose que VARBINARYpour le stockage byte[]?

Jon Skeet

Peut-il y avoir une conversion ou quelque chose qui se produit qui cause ce problème?

Oui. Vous appelez essentiellement toString()un tableau d'octets. Cela ne fera pas ce que vous voulez. Avez-vous regardé le SQL que vous exécutiez?

De plus, vous ne devriez pas produire une chaîne SQL comme celle-ci de toute façon - c'est une approche qui est vulnérable aux attaques par injection SQL ainsi qu'aux problèmes de conversion.

À la place, utilisez un PreparedStatementavec SQL paramétré et spécifiez directement les valeurs des paramètres ( PreparedStatement.setBytesetc.).

Plus largement, ce serait une bonne idée de ne pas rouler du tout votre propre code d'authentification - recherchez une bibliothèque existante qui s'intègre bien avec le cadre que vous utilisez, cela évitera probablement l'une des nombreuses vulnérabilités de sécurité. trop facile à créer en le faisant vous-même.

Articles connexes