What causes "not found in credential store" in moonD4rk/HackBrowserData?

No action needed if the browser genuinely has no stored secret — the retriever chain falls through to the next tier.

not found in credential store

Error message

not found in credential store

What it means

errStorageNotFound signals that the browser's account/label is absent from the OS credential store (macOS Keychain or Linux keyring/D-Bus Secret Service). findStorageKey wraps it with the storage name via %w so callers can match with errors.Is(err, errStorageNotFound) and the retriever chain can silently fall through to the next tier.

Solutions

No action needed if the browser genuinely has no stored secret — the retriever chain falls through to the next tier.
Verify Hints.KeychainLabel matches the exact keychain/keyring entry name for the target browser.
On Linux, ensure a Secret Service provider (gnome-keyring/kwallet) is running and unlocked.
Confirm you are on the same user account that created the browser's keychain entry.

Example fix

// before: guessed label
hints := masterkey.Hints{KeychainLabel: "Chrome Safe Storage"}
// after: exact per-platform label
hints := masterkey.Hints{KeychainLabel: "Chrome"}

Defensive patterns

Strategy: fallback

Validate before calling

// linux: confirm a Secret Service is reachable
// mac: ensure the keychain label exists before retrieving
if hints.KeychainLabel == "" {
    return errors.New("KeychainLabel hint is empty")
}

Try / catch

key, err := retriever.RetrieveKey(hints)
if errors.Is(err, masterkey.ErrStorageNotFound) || (errors.Is(err, errStorageNotFound)) {
    // browser has no stored secret: fall through to next tier
}

Prevention

Use the exact keychain/keyring label for the target browser.
On Linux, verify gnome-keyring/Secret Service is running and unlocked.
Run as the same user who owns the browser credentials.
Treat absence of credentials as a normal, non-fatal outcome.

When it happens

Trigger: Calling RetrieveKey (or findStorageKey) on darwin/linux where the Hints.KeychainLabel entry does not exist in the keychain/keyring; also asserted directly in TestFindStorageKey_NotFound.

Common situations: Probing a browser that has never saved passwords (no keychain entry created), wrong label casing/name in Hints, running in a container/headless host with no keyring, or a keychain that was locked/deleted.

Understand the failure class

Background: Record Not Found Errors: "not found", RecordNotFound, and "was not found" — what they mean and how to fix them — this error's family across 28 libraries.

Related errors

AI-assisted analysis of moonD4rk/HackBrowserData@0503d04d7a (2026-09-06). Data as JSON: /api/errors/0fb07435d387f9ce. Report an issue: GitHub.

Appendix: source

Thrown at masterkey/retriever.go:13

// Package masterkey retrieves Chromium master keys (per-platform retrievers + a cross-host Dump format).
// Firefox and Safari own their own key paths and don't route through here.
package masterkey

import (
	"errors"
	"fmt"

	"github.com/moond4rk/hackbrowserdata/log"
)

// errStorageNotFound: the browser's account is absent from the credential store (keychain/keyring).
var errStorageNotFound = errors.New("not found in credential store") //nolint:unused // only used on darwin and linux

// Hints bundles inputs for Retriever; each retriever reads only the field that applies to it.
type Hints struct {
	KeychainLabel  string // macOS Keychain account / Linux D-Bus Secret Service label
	WindowsABEKey  string // Windows ABE browser key (e.g. "chrome"); "" → ABE not applicable
	LocalStatePath string // path to (temp-copied) Local State JSON; only used on Windows
}

// Retriever obtains a Chromium master key from one platform source (DPAPI, Keychain, D-Bus, …).
type Retriever interface {
	RetrieveKey(hints Hints) ([]byte, error)
}

// ChainRetriever tries retrievers in order, first success wins (macOS V10: gcoredump→password→security).
type ChainRetriever struct {
	retrievers []Retriever
}

View on GitHub (pinned to 0503d04d7a)