Discussion :

[franck SEFIC]

salut à tous,

J'ai une table USER (Nom varchar(20), Prenom varchar(20), Mot_pass varbinary(MAX)). A partir de delphi, j'ai creee une fenetre de saisie pour remplir les trois champ. Apres avoir saisie les données dans le champ mot_pass qui est de type varbinary(MAX), j'ai un message d'error "Imposible d'acceder au champ mot_pass comme type text".

Comment contourner ce problème?

Merci pour votre soutien.

[pprem]

Bonjour

Par curiosité, pourquoi ce choix de type pour le champ en question ?

Quel ensemble de composants est utilisé pour l'accès à la base de données ?
si c'est FireDAC, peut-être qu'un remapping l'aiderait ? (ça peut se trouver au niveau du TFDConnection et de son assistant)

[ShaiLeTroll]

Effectivement, un mot de passe hashé par un SHA256 donne un binaire mais tu peux ensuite convertir ce binaire en hexa/base64 pour le stockage en base de donnée, les SELECT futur de comparaison d'un mdp avec son hash sera plus aisé ...
Beaucoup de lib propose un Digest en Hexa issu du SHA256
Evidemment, l'utilisateur saisi le mot de passe, double le champ de saisie pour une confirmation
n'utilise pas de TDBEdit mais de TEdit (+ passwordChar), vérifie que le mot de passe est bon, complexe, puis effectue le hash et tu fais manuellement un INSERT/UPDATE du mot de passe en SQL bindé.

Sinon, oui, tout le monde oublie la couche d'accès, ADO, SDAC, FD, ... il y en a tellement, des comportements variables surtout sur un sujet spécial comme un BLOB et un TBlobField

Il n'y a aucune raison de lire le mpd !
le mdp hashé est toujours utilisé dans un WHERE et ne pas oublier d'utiliser des Paramètres pour réduire le risque d'injection SQL.

[franck SEFIC]

Effectivement, un mot de passe hashé par un SHA256 donne un binaire mais tu peux ensuite convertir ce binaire en hexa/base64 pour le stockage en base de donnée, les SELECT futur de comparaison d'un mdp avec son hash sera plus aisé ...
Beaucoup de lib propose un Digest en Hexa issu du SHA256
Evidemment, l'utilisateur saisi le mot de passe, double le champ de saisie pour une confirmation
n'utilise pas de TDBEdit mais de TEdit (+ passwordChar), vérifie que le mot de passe est bon, complexe, puis effectue le hash et tu fais manuellement un INSERT/UPDATE du mot de passe en SQL bindé.

Sinon, oui, tout le monde oublie la couche d'accès, ADO, SDAC, FD, ... il y en a tellement, des comportements variables surtout sur un sujet spécial comme un BLOB et un TBlobField

Il n'y a aucune raison de lire le mpd !
le mdp hashé est toujours utilisé dans un WHERE et ne pas oublier d'utiliser des Paramètres pour réduire le risque d'injection SQL.

Evidemment, l'utilisateur saisi le mot de passe, double le champ de saisie pour une confirmation
n'utilise pas de TDBEdit mais de TEdit (+ passwordChar), vérifie que le mot de passe est bon: Je crois que ça marche bien avec le TEdit1.

Merci à vous tous.

[franck SEFIC]

Bonjour

Par curiosité, pourquoi ce choix de type pour le champ en question ?

Quel ensemble de composants est utilisé pour l'accès à la base de données ?
si c'est FireDAC, peut-être qu'un remapping l'aiderait ? (ça peut se trouver au niveau du TFDConnection et de son assistant)

Par curiosité, pourquoi ce choix de type pour le champ en question ? pour que le mot de passe ne soit pas lisible à partir de la base.

Quel ensemble de composants est utilisé pour l'accès à la base de données ? TADOconnection