There have been a lot of justified complaints about places requiring specific proprietary apps on specific proprietary OS that boil down to bog standard TOTP under the hood but with provisioning or maybe instructions designed to require the specified setup.
A few years ago I found out that the place holding my retirement assets exclusively supported an effectively TOTP app and that the setup protocol had been reverse engineered, so I set that up and have been able to use a linux TOTP app.
A little while back they decided to end support for it and I was dreading the deadline to switch to whatever they were going to. As is typical, I was having trouble figuring out in advance what hoop jumping would be required. What raised the stakes is that I had to first irreversibly turn off the current option. Well, I finally took the leap and found that details were scarce because effectively there aren’t any. You click on the link and a QRcode and an ASCII string show up and some brief instructions that say to do whatever your app says to do. No mention of TOTP, camera pointing, menu navigation, app name, OS, etc. I copied and pasted the string into my TOTP setup and everything worked. It seems to me that also greatly simplifies documentation and other support costs for the financial institution.
and where sometimes other parameters are present on the “URL”.
The IDENTITY, ISSUER and secret value will of course be replaced by actual values.
It should go without saying that you should never disclose the secret value - because, for all the crap, the only important part of it is the secret value. If you know the secret, you can generate the correct OTP code, now and forever.
The above is using the default SHA1 algorithm. Lately, I have seen one place (the government here) that is requiring SHA256 - so the algorithm parameter would presumably be present for their TOTP URLs and the secret value may be longer.
(Any length of secret should work with either algorithm. However it is obvious that too short a secret would be badness. It is less obvious that too long a secret, for the chosen algorithm, is also badness. So the secret should ideally be of the maximum sensible length for the chosen algorithm.)
Personally I just refuse to use any authentication that cannot be done with a standard TOTP application. Except with my employer where that is not a viable choice.
I guess I worded that poorly. By “instructions designed to require the specified setup” I meant:
instructions designed to require the specified proprietary OS / proprietary app
I was also reporting that one institution I have an account with switched to just stating that an authenticator app can be used without naming any app at all. (So that eliminated any need to change to a different institution, which besides being complicated because of investments being involved.) I didn’t dwell on the QRcode part because it wasn’t needed. Also, the text string was indeed simply the TOTP secret. Presumably the QRcode would have decoded to something like irvinewade’s example. If the text part had not been present, I would have used zbar to decode the QRcode.
I use credit unions for my day to day spending and local short term saving. I don’t have internet accounts with any of them because they require apps an OSes that I don’t support. I can do transfers in either direction with my investment account.
I guess people that interact with their banks over the internet with open TOTP 2FA don’t report it. I do see lots of complaints here and elsewhere about banks, employers, etc requiring SMS, email codes, proprietary apps/OS etc. and not supporting HW fobs. Trying to find out whether a bank actually supports standard TOTP or OAUTH* from its web site is pretty much impossible.
So if banks and investment firms exist that do 2FA better than the norm exist, I would like to try to build momentum for compiling a list of such banks or even a collection of posts naming 1 at a time.
I am finding that as the need for 2FA becomes more pressing, some entities are attempting to provide half-decent information on their web site and/or providing an FAQ just on 2FA - because it can be quite complicated getting a bunch of customers with varying levels of technical sophistication to get 2FA working. However that may be more targeted at existing customers where the entity is bringing in 2FA by force (and in any case my experience may be in the wrong country).
For example, the following is fairly helpful information (just as an example):
Before you add an authenticator
Use an authenticator you’re familiar with. Check if you already use one such as Google Authenticator or Apple’s Passwords.
Some authenticators can’t be used with your account because they don’t meet the SHA256 security standard. This includes Microsoft Authenticator.
If you want to use a password manager, it will need to support authenticator codes. You can check if your password manager does in your password manager settings.
Authenticators use a time-based code. Sometimes these are called TOTP or OTP. For the code to work, the device your authenticator is on needs to accurately show your local time.
I would consider that to be pretty close to “done correctly”. By the time you get to the bottom of that section, you pretty much know that you will be able to use it without resorting to a spyphone.
I agree, it actually goes well above and beyond what would be acceptable to me. I wish that sort of page was much more common in the US. Perhaps people in the EU will chime in on how hard it is to find an bank, broker, etc. where standard TOTP works. I also wonder how common suitable institutions are in the US. Or have I just been having bad luck?
I must confess to feeling a bit of schadenfreude that your example rejects the microsoft product on security grounds (but without considering whether it is likely spyware itself).
I noticed the entries for Fidelity and Penfed don’t match my current experience, so it looks like their crowdsourced info may not be regularly updated.
They have a github repo for it with issues, discussion, and pull request sections. I guess making a pull request would potentially result in the fastest update. Of course that would require a github account and the ability to work with whatever tools they use, but the issues route should be easy enough for those willing to have an account.
where that is not a viable choice.