Unfortunately FIDO2 seems mostly unused because people need to buy some physical keys (at least two) or have a recent Android 7+ to have it, using it with iPhone is a nightmare… and there are so few people having it that most web sites don’t use it yet, maybe never, most notably the banks that should be the firsts to adopt it, while it being a good idea, and really more secure than most things out there (SMS, OTP) just around 28 company’s use it (maybe more if I include some web site using Wordpress and other similar CMS self hosted solutions).
What people think about the new SQRL (Secure Quick Reliable Login) almost ready (technical documentation being finished, but program and web server for use already available for years).
Disadvantages to FIDO2: phishing is possible, especially if the authenticator app is not on the same machine or can’t get all the details of where (location URL) it is really and what is being requested (real URL location) (to see if they match).
Advantages to FIDO2:
- Free, open, anyone can implement / use it and not pay anyone else (just like username & passwords);
- one identity; the user can have the same identity in multiple devices;
- if someone does get the private key and password protecting it, the user still can recover access to online accounts and cancel access to that compromised identity while the attacker can’t because of the Rescue Code only show on the creation phase;
- can be used in multiple accounts even for the same web site;
- free programs/ apps to Windows, Wine, Android, iOS;
- because of the feature to allow the use on multiple account in the same web site, the user can use a personalized code/ text/ “secret” to access web sites, such that even if someone does have the private key and password still can’t access the web site without that extra information;
- user only needs to know one password (or if the program allows it not even that just use fingerprint or other biometric sensor);
- the web server only gets the public Ed25519 key, so nothing to loose that can compromise the user account if it gets known;
- web server only need to check if what is return to them is sign by some public key already know to them (less server process intensive);
- can be used to identify and authenticate or just as a second-factor;
- for banks and services like that (and anyone else for that matter) exist “ask” facility that allows 250 characters for personalized message and the same character length to the two possible answers. These allows web sites to present a QR code/ link that displays in the SQRL application the information (ex.: “Do you want to transfer 100 euros to IBAN 1200-12311-233-233-22?” / “Yes, I authorize the transfer” / “No, cancel!”) and two possible answers to choose from… that the user is digitally signing when it clicks one of them (or can just cancel the all thing and nothing happens). Banks are the obvious “client” for these function because of European law and maybe other international laws requiring them to use a secure second method of delivery to confirm login/ operations… but other web sites can use it to confirm e-mail/ phone/ postal address/ alternative access password/ account deletion and other important things where they may want to be sure it really is the correct user;
- username & password can still be used, allowing users to also use SQRL or web sites can give users the opportunity to allow just SQRL and disable username & password for increased security;
- SQRL can request for web sites to disable any alternative recovery access methods (that hackers usually use to bypass normal security measures) so that web sites know the user don’t want them available. And because SQRL it self has recovery built in (private key and rescue code need to be backup) from the start, web site operators can more easily accept to provide the functionality to users that request that on the SQRL interface (not enabled by default);
- it is also based on the URL, but it allows for domains to change their own domain and request the old SQRL identity to change SQRL to the new domain. Of course users must verify by some secure way that is really the web site that changed from URL to avoid phishing… that can be prevented in many cases, but users can disable some protections if they are sure they want to make that operation… is the same risk of introducing the username & password in a new URL, but the user at least can recover from the mistake if it was some sophisticated phishing attack and the user was fooled.
But everyone knows that operating systems and sometimes the hardware it self isn’t secure from backdoors/ spyware/ Trojans, for those worried with that would be nice for Nitrokey have a dedicated secure hardware device to allow superior protection. Needs to be small to be easily be carried in the pocket/ wallet/ on a cord around neck, water/ dust/ fall proof/ resistant.
Do other people thing is a good idea to have a dedicated device? Or smartphone/ tablet/ computer will be good enough?
