S-7 · NAVCOIN-KDF-2026-01 · v1.0 · Audit du 25 octobre 2026 · Lecture ~5 min
Résumé
NEXT est un client de bureau pour NavCoin. Le rapport examine la branche master de sakdeniz/next, en particulier le service de portefeuille léger server-lw.js et son fichier wallet.db.
Le fichier contient la phrase de récupération, les clés WIF et xpriv. Le chiffrement AES-256-CBC est utilisé, mais la clé est dérivée du mot de passe par un simple MD5, sans sel ni itérations. Toute personne qui obtient le fichier peut tester des mots de passe hors ligne, sans limitation de débit.
Le risque est local : il faut d’abord obtenir wallet.db. Ce n’est pas une attaque directe contre le réseau NavCoin.
Ce que contient le fichier
wallet.db est un fichier lowdb chiffré. Une fois déchiffré, il contient notamment :
- la phrase de récupération (
mnemonics) ; - les clés privées WIF des adresses ;
- la clé étendue
xpriv.
Le même fichier peut donc exposer l’ensemble des actifs dérivés de la phrase, pas seulement NAV.
Versions affectées
Le dépôt n’a pas de tag. Les 10 états successifs de server-lw.js ont été récupérés dans l’historique des commits. Tous les états à partir de l’ajout de la protection par mot de passe sont affectés.
| Date | Commit | Dérivation | Évaluation |
|---|---|---|---|
| 2019-02-10 | 3e6cf3078 | md5("password") constante | 0 entropie : fichier déchiffrable directement, sans attaque par mot de passe |
| 2019-02-13 | 7cd784876 | md5(mot de passe) | Affecté (S-7) |
| 2019-02-16 → 2021-01-20 | 8 commits suivants | md5(mot de passe) | Tous affectés |
Bilan : 10/10 états historiques examinés. Le dernier commit examiné (2021-01-20) n’apporte pas de correction.
Le problème
Le KDF n’est pas seulement faible : il est absent. La clé AES est le résultat hexadécimal d’un MD5 du mot de passe. Il n’y a ni sel, ni itération, ni authentification du chiffré.
Le mot de passe est en outre journalisé en clair dans certains chemins du service. Un journal collecté peut donc suffire, sans même attaquer le fichier.
Un mot de passe long et aléatoire ralentit l’attaque, mais ne corrige pas l’architecture. La recommandation est de migrer vers un KDF lent et salé.
Impact
Si wallet.db est copié, sauvegardé, synchronisé ou volé, l’attaquant peut travailler hors ligne et retrouver le mot de passe si celui-ci est faible ou réutilisé. Il obtient alors la phrase et les clés privées, puis peut transférer les actifs.
Le fichier est souvent inclus dans les sauvegardes et les répertoires synchronisés. Il doit être traité comme une clé privée, pas comme un simple fichier de configuration.
Périmètre et limites
- PoC reconstruit à partir de la même logique ; pas d’échantillon réel de wallet utilisateur.
- Le risque dépend de la force du mot de passe et de la capacité à obtenir le fichier.
- Le nœud complet
navcoin-coren’est pas couvert ; il utilise un autre chemin de dérivation. - Aucune version corrigée n’est identifiée dans le périmètre audité.
- Aucune donnée de victime, seed ou clé privée n’est publiée.
Recommandations
- Remplacer MD5 par Argon2id, scrypt ou PBKDF2-SHA512 avec des paramètres modernes.
- Ajouter un sel aléatoire par fichier et utiliser un chiffrement authentifié (AES-GCM ou ChaCha20-Poly1305).
- Supprimer les journaux de mot de passe.
- Migrer les anciens fichiers : un fichier existant reste attaquable tant qu’il n’est pas réécrit.
- Traiter
wallet.dbcomme un secret ; éviter les sauvegardes non chiffrées et les répertoires synchronisés. - Si le fichier a pu fuiter, créer un nouveau wallet avec une nouvelle phrase et déplacer les actifs.
Divulgation
Le rapport complet et les preuves restent restreints. Pour signaler un cas : security@frblockchain.icu. Ne pas envoyer de seed, de clé privée ou de fichier de wallet.