Security
Version 1.0, effective
What is in place to protect the Service and your data, stated without aspiration.
Credentials #
Passwords are hashed with scrypt and tagged with the algorithm, so a stronger algorithm can replace it at your next sign-in. The hash is never returned by any part of the Service.
Session tokens, invitation links, reset links, pairing codes and screen credentials are stored only as digests. A copy of the database would not let anybody sign in, accept an invitation or impersonate a screen.
The browser holds the session in an HttpOnly cookie, which no script on the page can read, and trades it for an access token that lasts five minutes. That token is held only in the page's memory, never written to browser storage, and is useless once it expires or its session ends.
#
Every request is checked against explicit permissions in the organization it names. There is no ambient administrator, and a permission that has not been granted is refused.
A permission can be limited to the whole organization, a location, a screen or a group, and the scope a request may carry is decided for each permission rather than accepted from the caller.
Separating organizations #
Every identifier in a request is checked to belong to the organization the request names before it is used, so one organization cannot reach another's content by guessing an identifier.
Screens #
A screen is paired with a one-time code and receives its own credential, which lets it read only its own instructions and report only on itself. One screen's credential cannot read or publish another's.
Hosting and transport #
The Service runs in Singapore, on DigitalOcean, Neon and Amazon Web Services, whose data centres hold recognised security certifications; the subprocessors page lists them. Every connection to the Service is encrypted, and the console sends browsers a content security policy and headers that stop other sites framing it.
What is not done yet #
There is no published penetration test, no bug bounty and no third-party security certification of our own yet.
Reporting something #
Email security@nayto.io with what you found and how to reproduce it; the same address is published at /.well-known/security.txt. We will confirm receipt, and we will not pursue anybody who reports a finding in good faith and does not take or keep other people's data while doing it.
How this document changes #
Every version of this document has a number and the date it applies from, both printed under the title. A change is published as a new version rather than an edit to this one, so what the document said on any day can be checked.
When a change matters to what you have agreed or to how we use your data, we tell you before it takes effect. Earlier versions are available from legal@nayto.io.