CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 36 Bitcoin

hww: add change password workflow

BBf30b1203 View source ↗
Public commit record

What the developer wrote

Authored by cedwies

73/100 · Adequate
hww: add change password workflow

Currently, changing the device password requires a full device reset
and restoration from a backup. This process is cumbersome and increases
the risk of user error or seed exposure during the restoration process.

This patch introduces a native "Change Password" workflow that allows
the user to rotate their device password without resetting the device.

The workflow:
1. Forces the user to re-enter the current password for security, even
if the device is already unlocked.
2. Prompts for the new password (entered twice).
3. Re-encrypts the stored seed and BIP39 entropy with the new password
using the Secure Chip for key stretching.

The implementation ensures that the wallet identity (Root Fingerprint
and BIP39 seed) is preserved, so the device remains paired and
functional with the same accounts (including passphrase) after the
password change.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new 'Change Password' feature to the BitBox02 hardware wallet. Instead of resetting the device and restoring from a backup, users can now change their device password directly. The wallet re-encrypts the stored seed with the new password while keeping the same accounts and identity. The change is a normal product feature, not a security fix, but it touches sensitive crypto code that protects the user's funds.

Recommended action

Treat as a feature commit, not a vulnerability patch. If auditing, focus review on keystore::re_encrypt_seed to ensure the BIP39 seed and root fingerprint are safely retained and that no plaintext seed material is exposed during the rotation. Also verify that the new endpoint cannot be reached in a locked or uninitialized state and that the secure chip event-counter assumptions in tests match production behavior.

Security signals we found

01

New privileged API endpoint added to an existing oneof (protobuf tag 30)

02

Workflow requires old-password re-authentication before password rotation

03

Re-encryption of seed material via secure chip key stretching

04

BIP39 seed and root fingerprint are copied and restored across re-encryption to preserve wallet state

05

Endpoint is restricted to InitializedAndUnlocked device state

06

No input parameters in ChangePasswordRequest, so no attacker-controlled data is parsed

07

Extensive unit tests included for success, failure, and state-preservation cases

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 4/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from BitBox02 firmware

Related watches

Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 69 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Limit SD erase file size

This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a fi…

CVE-2026-6682 referenced in commit messageMalformed FAT directory entry could cause excessive overwrite loopDenial-of-service via SD card tampering
2453f528by Marko Bencun+4−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 70 AI analysisMessage 66 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Validate mounted FAT geometry

This update adds a safety check when the BitBox02 hardware wallet mounts a microSD card. A malicious or deliberately malformed FAT filesystem could trick the device's file-system library into placing user data inside attacker-controlled bo…

Fixes integer-wrap / geometry confusion in FAT mount logicAdds explicit post-mount validation of filesystem metadataPrevents data area from landing inside attacker-controlled FAT sectors
01c017d6by Marko Bencun+21−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗