S-7 · NAVCOIN-KDF-2026-01 · v1.0 · Audited 25 October 2026 · ~5 min read
Summary
NEXT is a desktop client for NavCoin. The report examines the master branch of sakdeniz/next, in particular the light-wallet service server-lw.js and its wallet.db file.
The file contains the recovery phrase, WIF private keys and xpriv. AES-256-CBC is used, but the key is derived from the password with a single MD5, without salt or iterations. Anyone who obtains the file can test passwords offline without rate limits.
The risk is local: wallet.db must first be obtained. This is not a direct attack against the NavCoin network. Rating: medium — the attack requires access to the local file; it becomes critical if the file leaks.
What the file contains
wallet.db is an encrypted lowdb file. Once decrypted, it contains:
- the recovery phrase (
mnemonics); - WIF private keys for the addresses;
- the extended private key (
xpriv).
The same file can therefore expose every asset derived from the phrase, not only NAV.
Affected versions
The repository has no tags. The 10 successive states of server-lw.js were retrieved from commit history. Every state from the addition of password protection onward is affected.
| Date | Commit | Derivation | Assessment |
|---|---|---|---|
| 2019-02-10 | 3e6cf3078 | constant md5("password") | 0 entropy: file decryptable directly, no password attack needed |
| 2019-02-13 | 7cd784876 | md5(user password) | Affected (S-7) |
| 2019-02-16 → 2021-01-20 | 8 subsequent commits | md5(user password) | All affected |
Result: 10/10 historical states examined. The last commit examined (2021-01-20) does not fix the issue.
The problem
The KDF is not merely weak: it is absent. The AES key is the hexadecimal output of an MD5 of the password. There is no salt, no iteration and no authentication of the ciphertext.
The password is also logged in clear text on some code paths. A collected log can therefore be enough, without attacking the file at all.
A long random password slows the attack but does not fix the design. The recommendation is to migrate to a slow, salted KDF.
Impact
If wallet.db is copied, backed up, synchronized or stolen, an attacker can work offline and recover the password if it is weak or reused. They then obtain the phrase and private keys and can move the assets.
The file is often included in backups and synchronized folders. It must be treated as a private key, not as an ordinary configuration file.
Scope and limitations
- PoC rebuilt from the same logic; no real user wallet sample was tested.
- Risk depends on password strength and on obtaining the file.
- The full
navcoin-corenode is not covered; it uses a different derivation path. - No fixed version was identified within the audited scope.
- No victim data, seed or private key is published.
Recommendations
- Replace MD5 with Argon2id, scrypt or PBKDF2-SHA512 using modern parameters.
- Add a random per-file salt and use authenticated encryption (AES-GCM or ChaCha20-Poly1305).
- Remove password logging.
- Migrate old files: an existing file remains attackable until it is rewritten.
- Treat
wallet.dbas a secret; avoid unencrypted backups and synchronized folders. - If the file may have leaked, create a new wallet with a new phrase and move the assets.
Disclosure
The full report and evidence remain restricted. To report a case: security@frblockchain.icu. Do not send a seed, private key or wallet file.