IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Commentaires

  1. Avatar de SQLpro
    • |
    • permalink
    Citation Envoyé par CinePhil
    Bonjour,
    Tu pourrais nous en dire plus sur la partie déchiffrement ?
    Notamment pour ton exemple qui donne deux données chiffrées différentes pour le même chiffrement ?
    Microsoft ne communique pas sur l'algorithme de salage ni sur la manière dont cela est fait... Et heureusement. En matière de sécurité et de chiffrement moins on en sait et mieux cela vaut !

    Dans cette matière certains SGBD sont assez débiles pour informer de la nature précise d'une erreur de connexion... Ce qu'il ne faut jamais faire !
    Par exemple j'ai vu des SGBDR dire que le mot de passe était erroné, ce qui veut dire que le compte de connexion était bon !
    Dans SQL Server par exemple, le message en cas de connexion incorrect est toujours le même, mais la nature profonde est enregistrée dans un log interne consultable seulement pas les DBA....

    mais pour te répondre plus précisément, le déchiffrement ne pas pas de problème...

    Le même exemple en plus complet....
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    SELECT ENCRYPTBYPASSPHRASE('Le petit chat est vivant...', 'DUPONT')  AS NOM_CHIFFRÉ
    INTO T;
    
    INSERT INTO T 
    SELECT ENCRYPTBYPASSPHRASE('Le petit chat est vivant...', 'DUPONT')  AS NOM_CHIFFRÉ;
    les deux dupond sont mis dans la même table créée à la volée... Aucune autre colonne !

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    NOM_CHIFFRÉ
    --------------------------------------------------------------------------
    0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C
    0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2
    Déchiffrement :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT *, DECRYPTBYPASSPHRASE('Le petit chat est vivant...', NOM_CHIFFRÉ) AS NOM_DÉCHIFFRÉ
    FROM   T;
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    NOM_CHIFFRÉ                                                                   NOM_DÉCHIFFRÉ
    ----------------------------------------------------------------------------- -------------------    
    0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C    0x4455504F4E54
    0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2    0x4455504F4E54
    On voit que c'est du binaire car le type de données est "perdu"... mais on voit que les deux binaires sont maintenant strictement identique

    Il suffit de "caster" le nom binairement déchiffré :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT *, CAST(DECRYPTBYPASSPHRASE('Le petit chat est vivant...', NOM_CHIFFRÉ) AS VARCHAR(32)) AS NOM_DÉCHIFFRÉ_CLAIR
    FROM   T;
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    NOM_CHIFFRÉ                                                                   NOM_DÉCHIFFRÉ_CLAIR
    ----------------------------------------------------------------------------- ------------------- 
    0x020000007B7BBBFE50EC2C1DBB19BB1D478B24B20246C15C2ADFC1266C6133057575096C    DUPONT
    0x02000000CCD656C4B649865BF267BFC5A588D023E91FFEA83FEAD0D84485BF1552BB5BC2    DUPONT
    CQFD

    Selon toute probabilité, le salage est généré à partir d'une valeur attribué aléatoirement pour chaque mot de passe. Le sel et le mot de passe sont concaténés et transmis à une fonction de hachage et l'information ainsi calculée est stockée avec le sel dans la colonne de la table.
    Mis à jour 26/03/2024 à 20h45 par SQLpro
  2. Avatar de SQLpro
    • |
    • permalink
    Citation Envoyé par Karadoc
    (Il y a une petite boulette dans le lien vers le site de l'INSEE qui ne fonctionne pas)

    Oui et non... l'état de l'art à l'heure actuelle a (heureusement) bien évolué et on ne met plus les clés/mots de passe en direct dans le code, pour éviter entre autre qu'en cas de faille sur le serveur Web ces données sensibles ne soient accessibles directement.
    ça c'est un vœux pieu, mais dans les faits, la plupart des applications utilisent des mots de passe directement en clair dans le code; parce que les mécanisme en jeu dans MySQL/mariaDB n'obligent pas à cela et que l'effort de développement et/ou de rectification des applications écrites ainsi est colossal !

    On place les clés/mots de passe dans des fichiers (eux-mêmes chiffrés) dans un dossier hors des dossiers présentés par les serveurs web. La clé de déchiffrement des fichiers est, elle aussi, située dans un emplacement isolé (on peut même aller plus loin en utilisant un dongle USB et des mécanismes d'OTP si on souhaite un niveau supérieur, mais ça demande alors l'utilisation de librairies spécifiques).
    Le programme (script, appli...) lit à la volée la clé de déchiffrement première, puis lit les clés de déchiffrement (ou les mots de passe) d'accès aux ressources.
    Ce que fait intrinsèquement SQL Server ou Oracle.... Et qu'il faut faire à la main dans le code avec MySQL / MariaDB... perte de temps, complexité...

    Bien entendu, si on a un accès direct à la machine avec un compte qui a accès aux emplacements sécurisés ou s'il y a une faille dans le service web suffisamment grave pour provoquer un débordement de pile et accéder à des zones de RAM dans lesquelles on va retrouver les clés de déchiffrement, on peut avoir un problème. Mais on a quand-même sérieusement diminué les risques (et, de toutes façons, s'il y a une faille de sécurité suffisamment importante pour avoir un accès à la RAM, ou un accès superviseur sur le serveur, alors on peut aussi accéder aux données de la base en mémoire quelle que soit la situation).
    C'est bien pour cela que les enclaves sécurisé en mémoire sont faites... Mais cela n'existe pas dans MySQL/MariaDB...
  3. Avatar de Karadoc
    • |
    • permalink
    (Il y a une petite boulette dans le lien vers le site de l'INSEE qui ne fonctionne pas)

    Ce qui veut dire qu'il suffit d'avoir accès au code de l'application pour péter le chiffrement... C'est comme si vous fermiez votre voiture à clé en laissant les clés sur la porte !
    Oui et non... l'état de l'art à l'heure actuelle a (heureusement) bien évolué et on ne met plus les clés/mots de passe en direct dans le code, pour éviter entre autre qu'en cas de faille sur le serveur Web ces données sensibles ne soient accessibles directement. On place les clés/mots de passe dans des fichiers (eux-mêmes chiffrés) dans un dossier hors des dossiers présentés par les serveurs web. La clé de déchiffrement des fichiers est, elle aussi, située dans un emplacement isolé (on peut même aller plus loin en utilisant un dongle USB et des mécanismes d'OTP si on souhaite un niveau supérieur, mais ça demande alors l'utilisation de librairies spécifiques).
    Le programme (script, appli...) lit à la volée la clé de déchiffrement première, puis lit les clés de déchiffrement (ou les mots de passe) d'accès aux ressources. Bien entendu, si on a un accès direct à la machine avec un compte qui a accès aux emplacements sécurisés ou s'il y a une faille dans le service web suffisamment grave pour provoquer un débordement de pile et accéder à des zones de RAM dans lesquelles on va retrouver les clés de déchiffrement, on peut avoir un problème. Mais on a quand-même sérieusement diminué les risques (et, de toutes façons, s'il y a une faille de sécurité suffisamment importante pour avoir un accès à la RAM, ou un accès superviseur sur le serveur, alors on peut aussi accéder aux données de la base en mémoire quelle que soit la situation).
  4. Avatar de CinePhil
    • |
    • permalink
    Bonjour,
    Tu pourrais nous en dire plus sur la partie déchiffrement ?
    Notamment pour ton exemple qui donne deux données chiffrées différentes pour le même chiffrement ?
  5. Avatar de frfancha
    • |
    • permalink
    Clair et concis, lien à garder! Merci