Google is one of a very small number of email providers that support an alternative to passwords called OAUTH2. We do not currently support OAUTH with Google. Although we more than satisfy all their security and technical requirements, we've sent in multiple applications for their verification process; all of which have simply been ignored.
Fortunately Google also supports connecting with a username and password (the same as 99.9% of email providers) but Google turns this off by default (meaning you have to go to your settings and turn it on) and tries to scare you (and demonize us) by changing the wording from "allow password authentication" to "allow access from less secure apps."
Don't let this scare you. Basically we’ve set up a completely secure, sealed and self-contained environment that makes it impossible for anyone (even the creator) to ever access your password. This is exactly how we want it to be. Being trusted with your data is a major responsibility – one we take seriously.
Read on for some technical details...
Although many apps actually are less secure, in that they don't know how to properly secure passwords, we handle passwords in an extremely secure manner.
Google's notion of "less secure" runs the range of simply storing a password in the database in an un-encrypted form (really bad) to encrypting passwords, but still storing them in a database (still bad). If an app is simply encrypting the passwords and saving them in the database, there’s a major problem. The key has to be stored somewhere on the server (and other places too) This is similar to having a big secure safe, but storing the combination on a post-it note in the same room.
This is why we don’t store passwords in the database. It’s simply a terrible idea. Instead we use a key vault.
To quote Kamran Ayub in a blog post from last year.
"A word about how Azure Key Vault stores keys. It’s basically the most hardcore thing ever. If you opt for the Premium service tier, your key is stored on dedicated hardware called a Hardware Security Module (HSM). I had never heard of these so let me clue you in: they are devices where all they do is encrypt and decrypt data and never let the key leave their boundaries. That means, essentially, you present the data you want to encrypt to the device, it encrypts it using a key that nobody knows, and spits out the ciphertext for you to store in your system. Azure Key Vault also supports software-protectedkeys which can operate under the same conditions except they are not stored on a dedicated device. The HSM is validated to be FIPS 140-2 Level 2 compliant"
They encryption key cannot be accessed. It can’t be accessed by a computer. Nor can a human being access the device. To be level 2 validated:
"Security Level 2 improves upon the physical security mechanisms of a Security Level 1 cryptographic module by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access."
Doesn't HSM require a password?
Not exactly. A password to a HSM would make this entire exercise somewhat pointless. We would still have to store the password somewhere in Mago's code, which means that it would be on every developer's machine, it would be in source code control and it would be on the servers. It would also be available to employees and then who knows who else. Not cool.
Instead, we use certificates to access the key vault. This gets a little bit complicated, so I’ll keep this high level:
The certificates we use store three things:
- Organization name
- Our Public Key
- The cryptographic signature of a trusted third party
A public key is an encryption key that is not a secret. Public/private key encryption is an ingenious way to secure communication and establish anyone is who they say they are.
The really wonderful thing about certificates and Azure (the cloud platform Mago uses) is that the certificates are stored with the servers. They can’t be downloaded and the private key can’t be accessed.
So what does this all mean?
In short, when you enter your email account password into Mago, it goes directly into the key vault (it does not pass ‘Go’ and does not collect $200). It does so over SSL (so your password is also protected in transit to the servers) Then the key vault is both physically and cryptographically secure. Finally the connection to your email server is encrypted.
Once in there, only the email scanner application can retrieve it. From the specific servers it runs on. That’s it.