Hachage cryptographique robuste — Bonnes pratiques

Hashing vs chiffrement (ne pas confondre)

• Hachage : fonction à sens unique (objectif : empreinte, intégrité, stockage mots de passe).
• Chiffrement : réversible avec une clé (objectif : confidentialité).

Deux grands usages (et deux stratégies)

1) Stockage de mots de passe

Exigences : résister aux attaques offline (GPU/ASIC), donc algorithmes lents et “mémoire-durs”.

Recommandations (selon vos contraintes) :

• Argon2id (souvent recommandé quand disponible)
• bcrypt (très répandu, robuste)
• scrypt (mémoire-dur)

Bonnes pratiques :

• Sel unique par mot de passe.
• Paramètres adaptés (coût) et réévaluation régulière.
• Optionnel : pepper (secret côté serveur, séparé de la DB).

Anti-patterns :

• MD5 / SHA1 / SHA256 “tout seul” pour les mots de passe.
• Sel global partagé.

2) Intégrité de fichiers / messages

Ici, un hash rapide peut être OK (ex : SHA-256) si l’objectif est “détecter une corruption”.

Mais pour l’authenticité (empêcher un attaquant de forger), il faut une clé :

• HMAC-SHA-256 (ou SHA-512 selon contexte)

Quand utiliser SHA-256 / SHA-512

• Empreinte de contenu (checksum) : SHA-256 / SHA-512.
• Déduplication / cache keys : SHA-256 (souvent suffisant).

Attention : “intégrité” ≠ “authenticité”. Sans clé, un attaquant peut recalculer un hash.

Salage (salt) et pepper

• Salt : non secret, unique par entrée, stocké avec le hash.
• Pepper : secret, stocké séparément (ex : variable sécurisée / HSM / vault).

Exemple de schéma (conceptuel)

password_hash = KDF(password, salt, cost)
# Optionnel
password_hash = KDF(password + pepper, salt, cost)

Migration et montée en coût

• Stocker le “format” et les paramètres avec le hash.
• À la prochaine connexion, si paramètres trop faibles : re-hasher avec coûts modernes.

Voir aussi

• Memory Forensics — Analyse de la RAM
• Infrastructure as Code (IaC) Security