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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Taille d'un champ crypté en md5


Sujet :

PostgreSQL

  1. #1
    Membre averti
    Avatar de stc074
    Homme Profil pro
    Codeur du dimanche
    Inscrit en
    Janvier 2009
    Messages
    1 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Lozère (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Codeur du dimanche

    Informations forums :
    Inscription : Janvier 2009
    Messages : 1 014
    Points : 407
    Points
    407
    Billets dans le blog
    1
    Par défaut Taille d'un champ crypté en md5
    Bonjour, la taille d'un champ crypté (md5) peut-elle varier ?
    Merci.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par stc074 Voir le message
    Bonjour, la taille d'un champ crypté (md5) peut-elle varier ?
    Merci.
    Non, le retour doit être de 16 octets.

    ATTENTION : une fonction de hachage n'est en aucun cas une solution de cryptage !!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre averti
    Avatar de stc074
    Homme Profil pro
    Codeur du dimanche
    Inscrit en
    Janvier 2009
    Messages
    1 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Lozère (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Codeur du dimanche

    Informations forums :
    Inscription : Janvier 2009
    Messages : 1 014
    Points : 407
    Points
    407
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Non, le retour doit être de 16 octets.

    ATTENTION : une fonction de hachage n'est en aucun cas une solution de cryptage !!!

    A +
    Ah, je pensais que cela suffisait à crypter, je fais ainsi

    INSERT INTO table (nickname, pass) VALUES (?, MD5(?)); (requête préparée en Java)
    pass est le mot de passe saisi, peux-tu me confirmer que cela ne suffit pas, et si t'as un bon lien vers un tuto je suis preneur aussi.
    Merci beaucoup.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Un hachage est un algorithme qui convertit une donnée quelconque en un nombre binaire de façon à mieux ventiler les différentes valeurs. Le hachage s'avère utile lorsque la distribution des données est erratique (par exemple concentration de chaines de caractères commençant par M et très rarement par Z...). C'est généralement utilisé pour la distribution de processus dans des systèmes répartis afin de les faire fonctionner en parallèle avec un bon lissage de charge.
    Rien à voir donc avec du cryptage. Il n'est d'ailleurs pas possible de "décrypter" puisque le hachage est à sens unique. En sus, plusieurs données différentes peuvent conduire au même code haché (téléscopage) !
    par exemple, les chaines binaires suivantes :
    d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70
    et
    d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70
    Qui différent au 20e octet, donne la même valeur de hash :
    79054025255FB1A26E4BC422AEF54EB4

    Exemple avec PostGreSQL :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'::bytea)
    UNION ALL
    SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'::bytea)
    On s'en sert néanmoins parfois de manière détournée pour gérer des "signatures"... Ce qui est absurde !

    Si vous voulez du cryptage il faut utiliser un algorithme de chiffrement comme RSA, AES ou DES...

    Vous pouvez trouver cela dans la contribution ps_crypto. Néanmoins PostGreSQL n'est pas fiable au niveau du cryptage parce qu'il n'implémente pas de "salage" automatique du cryptage. Il est alors facile de casser le code par une cryptanalyse fréquentielle.
    Des SGBDR comme SQL Server ou Oracle utilisent un chiffrement automatiquement "salé" pour plus de sécurité....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre averti
    Avatar de stc074
    Homme Profil pro
    Codeur du dimanche
    Inscrit en
    Janvier 2009
    Messages
    1 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Lozère (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Codeur du dimanche

    Informations forums :
    Inscription : Janvier 2009
    Messages : 1 014
    Points : 407
    Points
    407
    Billets dans le blog
    1
    Par défaut
    Merci pour ces informations, je vais crypter mes mots de passe avant de les enregistrer dans la bdd, j'ai trouvé la classe Blowfish pour java, ça a l'air bien.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par stc074 Voir le message
    Merci pour ces informations, je vais crypter mes mots de passe avant de les enregistrer dans la bdd, j'ai trouvé la classe Blowfish pour java, ça a l'air bien.
    Au vu des nombreuses personnes qui confondent hachage et cryptage et ne maitrisent pas le cryptage dans les SGBDR j'ai écrit un article :
    http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Modifier taille d'un champ
    Par jmjmjm dans le forum Outils
    Réponses: 8
    Dernier message: 25/11/2016, 10h24
  2. Taille maximum des champs courants
    Par sabbish dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 29/11/2013, 13h48
  3. Problème avec un champs crypté en MD5
    Par jchevalay54 dans le forum Débuter avec Java
    Réponses: 11
    Dernier message: 19/12/2011, 12h20
  4. Recuperer le type et la taille d'un champ
    Par bassim dans le forum Bases de données
    Réponses: 4
    Dernier message: 04/11/2005, 20h50
  5. Modifier la taille d'un champ
    Par sbeu dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 23/03/2005, 16h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo