First and foremost, unauthorised access to Orbit must be prevented. Since there is more than one way to authenticate as a user in Orbit, all avenues of ingress are scrutinised for potential exploits.
Username & password
The simplest form of authentication is by using a username & password. Here, Orbit ensures that passwords are saved only as hashes in the database: Each password has a unique salt and goes through 10,000 rounds of SHA512 before it is saved.
Consider the time it takes the server to respond to a failed login attempt, as an example of a non-obvious security measure that Orbit Online has taken with Orbit. This may reveal whether a given username is valid since no hashing takes place when the username does not exist. Resulting in a faster response time. This is mitigated by delaying responses of failed attempts by a random amount of time.
Token authentication
API integrations do not use username & password authentication for access to Orbit. Instead, they possess a single bearer token that Orbit handles in much the same way as passwords (i.e., hashed multiple times).
ADFS
Orbit integrates with Microsoft Active Directory via ADFS. Here, much of the security relies on ADFS being secured properly by the customer. When ADFS directs a user to Orbit, with a signed SAML LoginRequest in hand, Orbit naturally performs all necessary signature verifications. Orbit also complements this with internal permission checks of the user logging in.
