90 lines
4.7 KiB
Markdown
90 lines
4.7 KiB
Markdown
# Security model
|
|
|
|
## Password handling
|
|
|
|
- The Credential Provider receives the password in Lithnet's secure password
|
|
control and keeps that `SecureString` for Windows serialization.
|
|
- A temporary managed string is unavoidable when creating the HTTPS JSON body.
|
|
The unmanaged conversion buffer is zeroed immediately with
|
|
`Marshal.ZeroFreeGlobalAllocUnicode`; managed references are released as soon
|
|
as each request completes.
|
|
- The broker uses the exact received value for both NTLM and AD `SetPassword`.
|
|
- There is no HMAC password, pepper, local password cache, Supabase password, or
|
|
other derived credential in this Windows path.
|
|
- Neither application logs request bodies or passwords. Deployment configuration
|
|
contains certificate thumbprints, not passwords or private keys.
|
|
|
|
## Transport
|
|
|
|
- HTTPS is mandatory on both links.
|
|
- Credential Provider to broker uses mutual TLS. The provider requires normal
|
|
Windows certificate validation and pins the configured server certificate.
|
|
- The broker requires a trusted client certificate and an explicit allow-listed
|
|
thumbprint.
|
|
- Client private keys are non-exportable and reside in `LocalMachine\My`.
|
|
- The NTLM validator rejects non-HTTPS redirects, URI user information, and hosts
|
|
outside its explicit redirect allow-list.
|
|
- Authentication and profile enrichment read only allow-listed HTTPS pages.
|
|
Profile bodies are capped at 512 KiB by default; portal cookies are
|
|
request-scoped and held only in memory.
|
|
|
|
## Profile minimization
|
|
|
|
- Administrative enrichment first verifies the employee number and reads
|
|
employee type/status, email, job title, and department from the incident
|
|
overview. Only after that match, it reads given names and paternal/maternal
|
|
surnames from the personal page plus street, exterior/interior number,
|
|
neighborhood, locality, state, and postal code from the location page.
|
|
- Administrative birth date, RFC, CURP, sex, blood type, marital status,
|
|
nationality, telephone, email lists, housing type, and emergency-contact
|
|
fields are ignored.
|
|
- Student enrichment reads only the matching student number, given names,
|
|
paternal/maternal surnames, email, career, street, neighborhood,
|
|
city/municipality, state, and postal code from known element IDs.
|
|
- Student CURP, birth date, sex, blood type, marital status, telephone, mobile,
|
|
guardian, medical, financial, and academic-history values are ignored.
|
|
- Incident details, calendars, photographs, manager names, and manager positions
|
|
are deliberately ignored.
|
|
- The employee or student number must match the authenticated `AD` or `AL` key
|
|
before role-specific metadata is synchronized. The two supplemental
|
|
administrative pages are never requested unless the incident page supplied
|
|
the matching employee number.
|
|
- If SGU changes its HTML, authentication and exact-password synchronization
|
|
continue without enrichment; existing AD metadata is not erased.
|
|
- Slow profile pages cannot change an accepted credential into a rejection. The
|
|
lightweight NTLM root is authoritative; enrichment has its own independent total
|
|
timeout.
|
|
|
|
Lab self-signed certificates are appropriate only for the isolated VM network.
|
|
Use an enterprise CA with revocation checking in production.
|
|
|
|
## Recovery and availability
|
|
|
|
The provider distinguishes an authoritative rejection from unavailable
|
|
infrastructure:
|
|
|
|
- `400`/`401`: fail closed and show an error.
|
|
- timeout, TLS/connectivity error, `429`, or `5xx`: submit the unchanged credential
|
|
to Windows. Windows must still validate it against AD or the cached domain
|
|
verifier, so this does not grant access without the last synchronized password.
|
|
|
|
Redis is deliberately not used for password continuity. A second persistent
|
|
password verifier duplicates attackable credential material, while a reversible
|
|
encrypted password becomes a credential vault. AD and Windows cached domain
|
|
logon already implement the required last-known-password behavior. See
|
|
[`decisions/0001-no-password-cache.md`](decisions/0001-no-password-cache.md).
|
|
|
|
The installer never registers a Credential Provider filter and never disables
|
|
Microsoft's password, PIN, smart-card, or Windows Hello providers.
|
|
|
|
## Operational controls
|
|
|
|
- Limit the firewall rule to the Domain profile and required client networks.
|
|
- Delegate the broker service account only to `OU=Usuarios-SGU` and its managed child OUs.
|
|
- Keep broker/client certificates short lived and rotate their allow-list entries.
|
|
- Monitor service availability and AD provisioning events without enabling HTTP
|
|
body logging.
|
|
- Test uninstall and the built-in password provider before broad rollout.
|
|
- Do not test a new build first on a physical production endpoint; use a VM with
|
|
a recent checkpoint and a known local administrator recovery account.
|