Password/Security overview

A screen that gives an overview of how healthy the user's passwords are, and a quick way to fix weak ones.

Strength distribution

• Chart showing how many logins fall into each score (Ridiculous, Weak, Moderate, Strong, Excellent)
• Tapping a category opens the item list with that score filter applied
• Logins without a password (PasswordScore.None) are not counted as weak

Scores are already stored unencrypted in password.password_score and exposed through LoginRepository.observePasswordScores(), so the chart needs no decryption. The list screen already filters by score (FilterUseCase), so the tap-through can reuse it instead of building a second list.

Scores are calculated when an item is saved (migrated v1 items keep their v1 score), so the chart is only as current as each item's last save.

Regenerate a weak password

The new password must never replace the working one before the user has actually changed it on the website. Otherwise a rejected or abandoned change locks them out.

• Generate a new password and copy it. The old password stays saved
• Open the service's website, if the login has one
• Save the new password only after the user confirms the change worked
• Quick options for length and symbols, since many sites reject some characters

PasswordGenerator lives in feature:item:create. The overview can depend on that module the way feature:autofill already does.

Breached passwords

Check passwords against the HIBP Pwned Passwords range API. It is free: no API key, no subscription, no attribution required (only HIBP's email and domain search APIs are paid). It uses k-anonymity, so only the first 5 characters of the password's SHA-1 hash ever leave the device.

• Opt-in, off by default. Nothing is sent until the user enables it
• Show breached logins as their own category, with a tap-through to the affected items
• Breached logins can use the regenerate flow above
• Send the Add-Padding: true header and discard padded rows (count 0)
• Handle offline and failed requests without marking anything as safe

Open question: storing results

Re-check everything each time the screen opens, or persist a per-item result? A persisted flag would be readable without unlocking (like password_score), so it should either be encrypted or accepted as leaked metadata deliberately.

Open question: entry point

• A navigation bar tab (next to Home, Connectivity, Settings), or
• A summary card on Home ("4 weak passwords, Review") that opens the full screen

Out of scope (follow-up)

• Reused passwords. Finding these means comparing plaintext, so either decrypt all passwords while unlocked or store a hash keyed from the ARK (never a plain hash). This is security-sensitive and needs its own design.

Start with LoginRepository.observePasswordScores(), FilterUseCase, and PasswordGenerator in feature:item:create; feature:autofill shows how the overview might depend on that module. Review the HIBP Pwned Passwords range API requirements, including k-anonymity and Add-Padding handling. The work is not fully defined until the result-storage and entry-point questions are resolved, then all listed overview, regeneration, and breach-check behaviors need coverage.