01
How we think about it
We hold two things that matter: the credentials that open a utility portal, and the bills those portals return. We design so that neither can be exposed in bulk by a single failure, and so that every access can be explained afterwards.
Least access, always
Data is scoped per organisation at the query layer, not just in the interface. A client session can only ever resolve its own connections, bills and tickets.
02
Credential handling
- Portal credentials are encrypted at rest and are never displayed back after submission.
- They are used only to fetch bills for the connection they belong to — never for payments or profile changes.
- They are never shared between clients, and never sold or disclosed to third parties.
- They are removed from active processing as soon as an authorization is withdrawn.
- LiteBill account passwords are stored only as salted scrypt hashes — we cannot read them.
03
Platform controls
- Encryption in transit for all client and portal traffic.
- Signed, expiring session tokens with server-side revocation.
- Administrative surfaces are gated separately from client surfaces and are not publicly linked.
- Rate limiting and lockout on authentication endpoints to blunt brute-force attempts.
- Bill documents are held in object storage with restricted, time-bound access.
- Structured audit logging across the pipeline — every stage transition is recorded.
04
Operational practice
- Changes ship through review; infrastructure runs from version-controlled definitions.
- Workers run isolated per stage, so a parser failure cannot reach credential storage.
- Failures are held for review rather than delivered — bad data does not silently propagate.
- Backups are taken regularly and restore procedures are exercised.
- Access to production is limited to named engineers and is logged.
05
If something goes wrong
- We investigate immediately and contain first — suspending affected connections or credentials.
- We notify affected clients without undue delay, with what we know and what we are doing.
- We support clients in meeting their own notification duties to account holders.
- We publish a corrective summary once the cause is understood.
06
Reporting a vulnerability
Responsible disclosure welcome
Write to security@litebill.in with steps to reproduce. We acknowledge within two business days and will keep you updated until it is closed.
We ask that you:
- Give us reasonable time to remediate before disclosing publicly.
- Avoid accessing, modifying or deleting data belonging to others while testing.
- Do not run denial-of-service tests or anything that degrades service for other clients.
- Never test against a live DISCOM portal — target our surfaces only.
We will not pursue action against researchers who follow these guidelines in good faith.
Questions about this page?
Our team answers policy and compliance questions directly.