Calendar Credentials and Access Authorization
When you Sign In With Your Calendar you authorize FreeBusy to access one or more online calendars that you own, whenever someone checks your availability. Depending on your calendar provider this authorization uses OAUTH or a password. If your calendar allows only password-based authorization, FreeBusy needs to save your password.
|Calendar Provider||Requires saving your password|
|Microsoft Exchange||No if signing up entire organization,|
Yes if signing up individual accounts
|WorkMail||No if signing up entire organization,|
Yes if signing up individual accounts
Rest assured that for calendars where we need to save the password we take extra precautions to encrypt your password and not make it directly accessible to FreeBusy staff. All data is encrypted both in transit and at rest using high-grade industry-standard security with the utmost care for your privacy.
FreeBusy is committed to Enterprise security
We take security very seriously and we invest in a complex set of safeguards to protect your calendar credentials and calendar data. FreeBusy staff does not have access to your calendar data. In addition to data encryption in transit and at rest, when you purchase Enterprise or Dedicated plan you can request compliance audits for a variety of assurance programs, including:
Access controls and encryption keys are segregated such that no one person or machine has direct access to all the pieces necessary to access or utilize your credentials. Your data is protected against malicious attackers, whether external (who might have gained control over one of the machines) or part of our staff (on the development or operations teams). Multiple coordinated breaches or individuals working together are necessary to compromise the data.
We encrypt all calendar access credentials whether they are passwords or OAuth refresh tokens. Data is encrypted with a AES 256-bit key. At all times, whether in storage or when loaded in memory by the production machines, this AES key is itself encrypted with another RSA 4096-bit key (aka key wrapping). The only moment the AES key is in the clear (unwrapped) is inside the function call that performs the decryption.
FreeBusy is built on Windows Azure cloud services. The wrapped AES key is stored in Azure Storage together with the rest of the user account details. The service runs on machines utilizing the latest Windows Server OS. The wrapping RSA key-pair is packaged as a X.509 certificate and stored in the local machine certificate store provided by the Windows Server OS. The key generation ceremony is local to the production machines and happened on the first deployment such that the wrapping RSA key-pair only exists in the certificate store of the production machines and nowhere else. Access to the RSA key-pair on the production machine is restricted to the application Windows OS service account.
Why this choice for keys and key wrapping?
DevOps staff does not have access to the Windows OS service account and cannot read the RSA key-pair from the local certificate store. DevOps staff also does not have access to the Administrator account on the production machine. The password for the Administrator account is generated randomly at deployment time and then thrown away. If we have problems with a production machine that would necessitate Administrator access to fix, we throw it away and rebuild new one.
For your protection we do NOT backup the RSA or AES keys so as to not create further copies that would have to be secured. This is perhaps they only case known to us where not creating a backup leads to more protection. If a catastrophic event were to happen the consequence of losing the keys is small: all users would have to reauthorize FreeBusy (for calendar providers who support OAuth) or re-enter their password. It's a small price to pay for the extra security.
Key Management for Enterprises
Companies who purchase FreeBusy for Enterprise get their own dedicated set of encryptions keys, created and managed using Azure Key Vault, rather than using the general, multi-tenant keys described above. The algorithm for protecting credentials remains the same, however dedicated keys are generated and stored in hardware security modules (HSMs) rather than in Azure Storage. Key operations are done inside the HSMs, which are certified FIPS 140-2 Level 2, allowing the enterprise to audit key usage.