Hi,
According to the Pro 5.9.3 (2019-03-12) Changelog:
Important: Replace Google QR Code API with an iThemes Security hosted solution. Google’s API will be shutdown on March 14th, 2019. If you’d like to generate QR codes locally, a plugin is available in the members panel under “Plugins”: iThemes Security – Local QR Code.
+++++ To prevent any confusion, I’m not iThemes +++++
That’s interesting (and obviously I hadn’t seen that, so thanks!), although I don’t know to what extent it applies to the free plugin.
To be clear, I’m not questioning the legitimacy of iThemes having a QR Code API — it seems like a valid option — I just want to know what information it collects and how that data is handled. The QR Code generation option within the Users setting doesn’t mention this, the privacy policy link the free plugin settings have for other remote API options is broken, and the privacy policy to which the link on the iThemes website goes (which is for Liquid Web, which now owns iThemes) doesn’t say anything about data gathered by their plugins.
… although I don’t know to what extent it applies to the free plugin.
As of iTSec (free) release 8.0 the Two-Factor Authentication (TFA) feature is no longer a Pro only feature. So all old (Pro) Two-Factor Authentication changelog entries now also apply for the free plugin.
Also, is information transmitted to a remote service if I don’t generate a QR Code? (I use email tokens.)
That is a very interesting question!
What is important to know is that the QR Code API is only used by the Mobile App authentication method (not by the other 2 methods: Email and Backup Authentication Codes). So that means if only the latter (2) (or only 1 of them) are (is) selected for the Authentication Methods Available to Users setting the QR Code API will never be used.
As an interesting side note, I noticed that despite not selecting the Mobile App authentication method, the entry as seen below is still added to the iTSec plugin suggested policies in the Privacy Policy Guide:
A QR code image is generated for users that set up two-factor authentication for this site. This image is generated using an iThemes hosted API. As part of generating this image, your username is sent to the API. This data is not logged. For privacy policy details, please see the iThemes Privacy Policy.
IMHO that is a bug.
Also if the Mobile App authentication method is selected (and thus available for users to configure), the QR Code API will only be used when users either edit their profile or choose (to configure) the Mobile App method during the TFA setup flow, which may be triggered on login.
In my next post I’ll get back to you about what info exactly is provided to the QR Code API.
As promised below the data that is send to the QR Code API:
– the (tsn:)username
– 32 chars secret
– the site name (tsn)
This info was extracted from the get_google_qr_code() method in the better-wp-security/core/modules/two-factor/providers/class.two-factor-totp.php file.
Note iThemes did not change the method name when switching from the Google QR Code API to using their own QR Code API. However the mehod’s code clearly shows it is now using https://qr-code.ithemes.com/.
Additionally I managed to fix the bug in the Privacy Policy Guide.
If you are interested I can provide you with the fix (it may take a while before this bug appears on iThemes radar).
-
This reply was modified 4 years, 2 months ago by
nlpro.
Okay, that is very helpful, although I have some remaining questions:
At the risk of sounding very dumb, what is “tsn” in this context?
Is the 32-character secret segment (salt?) arbitrarily generated, or is it derived from some kind of user personal data? Is it unique to a specific user or to a specific request? (In other words, is it an identifier?)
I’d still be very keen to know what privacy policy the API calls are covered by. I know you’re not iThemes, and this seems like a “them” question, albeit an important one.
Aside from the procedural details in terms of disclosures, there is a significant security question, which may reveal my ignorance of the technical particulars of app-based authentication: Am I correct in assuming that any QR Code generated using the same input data you note would be able to generate equally valid tokens? If so, that would suggest that the API server (or indeed any API server used for this purpose) would be able to recreate the authentication tokens the user generates unless the generation data is hashed or encrypted in some way that precludes that.
Thanks!
tsn = the site name
So it’s just an abbreviation for my own convenience 😉
When the first argument (username) is passed it is done in the format:
tsn:username
So the username is preceded by the site name with a colon inbetween.
Is the 32-character secret segment (salt?) arbitrarily generated, or is it derived from some kind of user personal data? Is it unique to a specific user or to a specific request? (In other words, is it an identifier?)
It seems to be totally random as it’s generated using the WordPress Core wp_generate_password() function. On top of that the result is converted into base32 encoding.
So, no IMHO this is probably not an identifier, however it does get stored per user in the wp_usermeta table (meta_key = _two_factor_totp_key). That seems to indicate the “secret” is normally (auto) generated once per user but users do have the option to regenerate the secret manually.
tsn = the site name
Ah!
Thanks for the explanation, that’s very helpful.
