How login credentials are stored as auth keys

When you log in to KiddyCash — whether as a parent managing a family wallet, a school administrator, or a business operator — the platform does not store your raw password or PIN in its database. Instead, it immediately transforms your credential into an auth key: a deterministic, namespaced token that represents your identity within a specific context. Understanding this mechanism matters when you are debugging failed login attempts, reconciling access across multiple roles, or investigating why a credential change did not propagate as expected.

Why namespacing exists

KiddyCash supports several distinct user contexts on a single account: a parent can also be a business owner, a school can have multiple admin roles, and a child’s wallet may be linked to both a family and a school subscription. If credentials were stored in a flat, global format, a PIN reset in one context could silently invalidate access in another — or worse, create a collision between two roles sharing the same phone number.

To prevent this, KiddyCash prefixes every credential hash with a namespace identifier before storing it. The namespace encodes the portal type (family, business, school), the account tier, and the region. A parent in Nairobi logging in with a KES-denominated family wallet generates a different auth key than a business operator using the same phone number, even if the underlying PIN is identical.

How the auth key is constructed

When you submit your credentials at https://kiddy.cash/login, the following happens server-side:

  1. Identifier normalisation — Your phone number or email is canonicalised (E.164 format for phone numbers, lowercase for email).
  2. Namespace prefix injection — A namespace string is prepended, encoding your portal context, account type, and a platform-level salt.
  3. Hashing — The namespaced string is passed through a one-way hashing function. The output is the auth key stored in KiddyCash’s credential store.
  4. Session binding — The auth key is bound to a short-lived session token returned to your client. The raw credential never leaves the server after step 3.

This means KiddyCash cannot reverse an auth key back to your original PIN. If you forget your PIN, the only resolution path is a reset — see how to reset a lost PIN for the full recovery flow.

Changing your PIN and key rotation

When you change your account PIN, KiddyCash does not update your existing auth key — it generates a new one and atomically replaces the old entry in the credential store. Any active sessions holding the previous auth key are immediately invalidated. This is intentional: it ensures that a leaked session token cannot survive a credential change.

If you manage a business account with multiple operators, note that each operator’s auth key is scoped to their own namespace. Rotating your own PIN does not affect co-administrators.

Edge cases and failure modes

  • Duplicate phone numbers across portals: Because the namespace is part of the key, the same phone number can legitimately produce different auth keys in the family and business portals. A login failure in one portal does not indicate a problem in the other.
  • KYC/KYB re-verification: After a KYC or KYB review cycle, namespace metadata may be updated, triggering a forced auth key rotation. You will be prompted to re-authenticate.
  • Subscription context: Auth keys carry no subscription state — your access to features like campaigns or badges is resolved separately at the session layer. For background on how subscriptions are structured, see what’s new in subscriptions in KiddyCash and a closer look at subscriptions in KiddyCash.