Security

Raposa Aval exists to make high-stakes actions provable. That only works if the service itself is hard to tamper with. This page states what is in place today; if something is not listed here, assume it is not implemented.

Credentials

• API keys and the operator panel password are stored as SHA-256 hashes. The plaintext is displayed once at issuance and never written down by us — a lost key is replaced, not recovered.
• Revocation is immediate: a revoked key fails on the next request.
• Webhook signing secrets are stored in full, because signing requires them, in a table separate from the keys. A customer can rotate its secret at any time through the API.

Isolation between customers

Each approval records the key that created it. A client key can read only its own approvals; a request for another customer's approval returns 404, which does not reveal whether that identifier exists. Deciding an approval is restricted to operator keys.

Audit chain

Every event — creation, decision, expiry, webhook attempt, key issuance — is appended to a hash chain: sha256(prev_hash + timestamp + event + approval_id + actor + payload). Changing, inserting or deleting an entry breaks verification from that point onward, and verification can be run on demand. Secrets and API keys never enter the payload.

Outbound callbacks

Webhook bodies are signed with HMAC-SHA256 using the customer's own secret. Target URLs must be public HTTPS: addresses that resolve to loopback, private, link-local or reserved ranges are refused when the approval is created, and redirects are not followed. Delivery is retried three times after the first attempt and every attempt is audited.

Network and hosting

• The application binds to loopback only; TLS terminates at the reverse proxy in front of it.
• Certificates renew automatically; expiry is monitored.
• The agent signing key (Ed25519) was generated on the server, is readable only by root, and has never been transmitted anywhere.

Availability and recovery

• Automated checks every five minutes cover the landing pages, the API, the authentication boundary and the public form; failures are logged as errors on the host.
• The database is backed up daily using a consistent snapshot, verified with an integrity check, compressed, and kept for 14 days.
• Changes are deployed from version-controlled sources with a backup of the previous state taken first.

Testing

The service ships with an automated test suite covering the approval lifecycle, webhook signing and retries, customer isolation, the public form, audit export and listing behaviour. The isolation tests were verified by reintroducing the flaw they guard against and confirming they fail.

Reporting a problem

Write to abuse@dcescrypt.com. Tell us what you found and how to reproduce it. We answer within one business day, we will not pursue you legally for a good-faith report, and we will credit you if you want to be credited.