Security practices

This page describes the security behaviour of TDACorp Identity, the shared sign-in, session, token and authorization service operated by TDACorp Private Limited (an Indian company, incorporated 17 July 2026). It covers the sign-in and account pages, the OpenID Connect and OAuth 2.0 provider endpoints, the account API, the administrative API and console, and the background jobs that serve them.

The platform is in pre-production. Where a protection is built and running, the page says so in the present tense. Where a protection is designed but not built, or is built and switched off, the page says that instead and repeats it in the final section. Nothing here is a statement about a product built on top of this platform: such a product enforces its own authorization in its own database and has its own notice.

A written threat model exists in the repository, with numbered threats, the mitigation for each, the residual risk and the blast radius. The table below summarises it in plain words. Status uses three words only: Mitigated (the control is built and tested), Partly mitigated (built, with a stated gap) and Open (a known gap with no control yet).

Passwords, passkeys, authenticator codes, recovery codes, magic links and federated sign-in each offer a different level of protection. The assurance level (AAL) follows the NIST SP 800-63B vocabulary used by the platform specification.

How a password is stored

A password is put through Argon2id with parameters pinned in this platform's own code rather than left to a library default, so a routine dependency upgrade cannot quietly weaken them. The parameters are recorded with each hash, and an account's hash is upgraded to the current parameters the next time its owner signs in successfully.

What a new password must satisfy

The same policy applies when you register, set or change a password, accept an invitation, or finish recovery. It is deliberately small: it avoids composition rules and refuses only what no person would call a password.

Breached-password checking

When you register, set or change a password, accept an invitation, or finish recovery, the new password is checked against the Have I Been Pwned corpus using its range API. Only the first five hexadecimal characters of a SHA-1 digest of the password leave this system, with a padded response so its size reveals nothing. The comparison happens here, and no account identifier or email address is sent.

A session is a server-side record, referenced by an opaque cookie. Only a SHA-256 digest of the cookie value is stored. Every request to the account pages looks the session up in the database rather than trusting the cookie alone, so revoking a session, or deactivating an account, takes effect on the next request.

Cookie attributes

The __Host- prefix makes a browser refuse the cookie unless it is Secure, has path / and has no Domain attribute, so a sibling subdomain cannot set or overwrite it.

Session lifetimes and limits

What ends sessions

Rotation and reuse detection

Refresh tokens rotate on every use, and a token that was already used is remembered. If a retired token is presented again after a 10-second retry window, that is the signature of a stolen copy being replayed: the whole token family and its session are revoked, the account's authorization version is bumped so tokens already issued stop being accepted by anything that checks, and the event is audited. The short window exists only for the legitimate case of a client retrying after a dropped response. The sender-constraint check is applied after reuse detection, so a stolen token presented under the thief's key still counts as reuse.

After a reuse, a background job also ends every other session, refresh token family and personal access token of the account (only those created before the reuse) and emails the account owner that a reused sign-in token ended their access as a precaution. That email is a security notice that cannot be switched off.

A session is a bearer credential: anything that can replay it speaks with your full authority while it lives. So the operations that would turn a short-lived theft into durable access ask you to prove presence again with a passkey or an authenticator code (or, for an account with a linked provider, a sign-in through that provider).

Operations that need a fresh second factor

At the end of every sign-in, after the factors have been checked, a risk engine assesses the attempt and decides to allow it, to demand a stronger factor, or to refuse it. An unfamiliar browser, place or pattern may be asked to confirm with a stronger factor. It is a rule-based score, not a machine-learning model, and it never uses advertising or behavioural profiling data.

Every outcome and the signals behind it are stored with the sign-in transaction and audited.

Sign-in, recovery, token and API endpoints are rate limited. The counters are kept in the database so concurrent attempts cannot slip past a shared counter, and a request that exceeds a limit is refused with HTTP 429 and a Retry-After header. Account email sends are capped. The exact limits are not published.

Account recovery is ordered by strength, and the flow offers only the strongest path available to you. Every recovery link is single use, valid 15 minutes, and bound to the browser that requested it (a link opened elsewhere requires a new request).

Key hierarchy

A database test census fails the build when a column that looks like a plaintext secret appears, and a database check on every ciphertext column refuses a value too short to be a real ciphertext, so a plaintext string written into a ciphertext column fails at the database.

Security-relevant events are written to an append-only log in which each row is chained to the previous row by a hash. The database refuses UPDATE and DELETE on it. Each event carries identifiers and hashes rather than names or email addresses; an address in a payload appears only as a hash plus its last two characters.

A support tool strips credentials, tokens, cookies, private key material, password hashes and email addresses from any HAR file or log bundle before it is stored, and refuses images and archives rather than pretend to scan them.

Runbooks exist for signing key compromise, a client key compromise, a database read breach, an administrator account compromise, an audit chain mismatch, exposed support material and a locked-out sole administrator, plus a notification runbook. Each step in them is tagged as built or not built, so none describes a future state in the present tense. The specification names reporting clocks (6 hours to the national CERT and 72 hours to the Data Protection Board for the classes it lists); the notification runbook carries a template for both. The vulnerability disclosure page says how to report a problem to us, and the incident response page describes how an incident is handled.

• TDACorp holds no security certification. There is no SOC 2 report, no ISO 27001 certificate and no third-party audit.
• No outside party has verified these statements. They are written by the team that maintains the code, from the code.
• This page describes the identity platform only, in pre-production. A product built on this platform enforces its own authorization in its own database.
• It is not a threat model, a penetration test report or a claim that the platform is unbreakable.
• Production hardware or cloud key management is not in place. Pre-production runs a software key provider, and the weaker custody described in the cryptography section is real.
• No uptime or recovery objective is promised. Service level objectives exist as design targets and only some of the metrics behind them are emitted.
• Background work (exports, erasure, key rotation, webhook delivery, expiry sweeps) is driven by a daily scheduled job and by ordinary traffic on the current hosting plan, so it can run up to about a day late.
• There is no permanent account lockout; failed attempts are throttled, and the owner is emailed when repeated failed attempts hit the account.
• A break-glass activation is alerted to the operator only by the daily monitor job, so the alert can be up to about a day late.
• The breach check is best effort: it depends on an external service.
• The resolution of the client address used by per-address limits has not been verified against the live edge.
• Scheduled audit anchoring and automatic audit pruning are off in the committed configuration, and offline standing verification is not built.
• Backup jobs are written but have not been run, and no restore time has been measured.
• Federated sign-in code exists but no provider is registered, so none is offered today.
• Revoking a single session does not need step-up unless an operator enables the flag.
• Imported older password hashes are not verified; those accounts must set a new password.
• The cost of the decision API's event stream on the hosting plan has not been measured.
• The platform has not been through the OpenID Foundation conformance suite.
• Audit retention is not a setting an organization can change; the page quotes defaults for session lifetimes and the step-up window.

The disclosure policy exists because we expect to be wrong somewhere. If you have found where, tell us at security@tdacorp.in.