Hi, apologies for only getting back to you on this now.


That's our process as well.


The legality issue of the Google ToS is news to me, could you point me to which items are contentious and in which jurisdiction(s) they're illegal? We do not want anyone to break the law. Please don't send me a "lmgtfy" link, it's demonstrably counterproductive in this specific case.

Google is currently the only OpenID provider we support. This does not mean we won't support any others in the future. If you want to suggest another I'll have a look into it and assign development resources to it as and when they become available. Developing the following work-processes (and securing/supporting them) was not possible given the required time-frame:
1. user sign-up
2. user human check (e.g. captcha)
3. user email verification.
4. user password recovery/reset
5. user secure password storage
6. user secure password transmission
7. user authorization
8. user authentication
9. user 2FA implementation (and items 4 through 8 as above for this as well)
10. all the support structures (and staffing) to support the above for literally hundreds of users on day 1 of going live.
This is the "security wheel" in its base form. I see so many companies implementing all that thinking they can just go ahead and do it perfectly on the 1st try and almost succeeding (at worst) or failing miserably (at best). We decided on a different route, and OpenID is it.


The Google accounts (our OpenId provider) choice wasn't because of 2FA instead of OpenID, one of the many reasons for settling on it was because this particular OpenID provider includes 2FA.