A Great 2-Factor Auth solution is going :-(

Clef, which is in my opinion one of the easiest 2FA solutions out there is closing on the 6th of June. So Let's talk more about 2FA and its history. and how Clef is involved

Two Factor Auth. Something great that actually predates a the Internet by a lot. Passports and ID cards could be seen as one of the first forms of Actual 2-Factor Authentication. This doesnt count as the Knowledge and Possession type of 2FA that is commonly used today but Instead it uses Possesion and your own body. of course back in the past it was easy to fake those cards, so it was very brittle, especially considering that the card is not only the Proof for your Identity but the data written on the card is used to connect yourself to your Identity, meaning if someone could replace the photo on the card and write the name and data of someone else on it, they could easily pretend to be that person, as long as, of course, in case the impostor is pretending to be an other exisiting person nobody who actually knows that person comes along, notices it and blows the cover. Of course if someone knows the impostor he would also be blown on the spot, but it is still a very brittle type of Authentication with the Quality of the Possession, which has risen by a LOT since the 21st century with holographic copies of the photo also being on the card and small pieces of a UV reacting material and similar ways to prove that the card is real.

Another type of commonly used 2FA is involving Money, or rather banks. when you go shopping and want to pay with whatever type of payment card you have available, whether it is the credit card or the "EC-Card" used a lot in Germany, the procedure is similar.
There's a magnetic stripe and a chip on the card, depending on the type of reader either the stripe or the chip is used. the most common way to handle it is (or at least was) using the data on the stripe (possession) and the signature of the owner (biometry, in this case, your handwriting) or using the stripe data and the PIN (knowledge) Later on, the chip came and opened the way for probably the first commonly used cryptographic 2 Factor solution. Although I don't know the specifics it probably works in a way that, at least when chip and PIN is used, that the chip will get the PIN directly as authentication along with the transaction data and sign the transaction data, that's at least the most simple reliable way to use the chip properly. and the chip is far better than the magnetic stripe from any angle:
You can't accidentially delete the chip data like you can with magnets, I know someone who has his stripe erased by the fields emmited by his mobile phone multiple times.
Also the chip should at least act like a smartcard and therefore like a black box in regards of transaction verification. You throw in the Transaction data and the PIN and get the verification data which goes to the bank, this means that you cannot read out the chip data, while it is relatively easy to read and copy the magnetic stripe to create fake cards, which makes the possession factor relatively brittle for the stripe from both security and destructibility factors

I dont know since when Banks have 2 Factor for Transactions but they sure have it for a long time with the TAN Lists and other more or less nice methods. and they evolved into a lot of way but some banks are still behind the loop with the only things being able to use are TAN Lists, SMS, or going really ugly, App-based TAN generators (why these are ugly, read on, it will be explained further below), while other banks offer TAN generators which are sometimes more sometimes less expensive, sometimes use your card and other times use an activation code you get by paper mail. and then, there are methods like HBCI which work by directly communicating with your computer.

Of course the internet came to be common place for a lot of things like email, shopping and so on and a lot of junk along with it. Most annoying are things like phishing and MITM attacks, given that HTTPS wasnt very common back then, these were common things and easily made users give up their account data to malicious people.

Of course that isnt funny. And Google thought of great stuff by offering Two Factor Authentication at a large, international scale. The fact that they used the completely open TOTP Algorithm, invented by OATH, the Initiative for Open Authentication, certainly helped the spreading of it, because people didnt have to use the Google Authenticator app, but could use an other one that also supports the standard or make their same, they also could create an air-gapped device which does nothing but generating TOTPs.

this, in combination with HTTPS makes it very hard to get into the accounts because attackers have a few minutes at best to actually sign into the account.

Over the last 7 years Two factor spread far and wide so that there are Two factor implementations for many web systems, including WordPress, which is the base of this blog and many others. also there is a ton of client software for generating these codes, and it wouldn't even surprise me if someone would be funny enough to create one for DOS or an 8-bit microcomputer.

Well TOTP has enough weaknesses and it is far from perfect, and slightly annoying to be honest. and so came quite a few security companies that try to make it better, one of them was clef, which offered a solution that was free for the users and for the admins it was at least free if you aren't too large. I have used clef for a very long time and still use it while developing to make the login quicker to make login debugging easy.

Well the intresting Question is, what is it that makes clef so special (and in my personal opinion, awesome). one of these is the simplicity. The first part of registering is the hardest, but even that is relatively simple. you get the app and then register with your name and email address, no password needed. then you set a PIN (or use your fingerprint) to protect the app from others.

I can already see some who may ask "So what are the Factors?", well even though from the website standpoint there's just one factor, the clef account, it's secured by both the PIN and the RSA key that the application generated and of which the server got the public key from the Registration. of course one could argue that the key is just another knowledge factor and could easily be grabbed by an attacker with the right permissions, which is no problem especially on android.

after that you can go to any clef-enabled website and (if needed click on "sign in with clef" or similar) a bunch of lines moving up and down, also dubbed the "clef wave") will appear. you start the clef app, enter the PIN and scan the moving barcode. The smartphone will connect to the clef servers and sign the data in the code and the login website will throw a redirection. if you havent used clef on the computer yet, you will be redirected to a clef site and will be asked on your phone to verify the location on your computer, something they call "true logins", which is a nice concept since it really helps against impersonation attacks and the tinfoil-hat users can go as far as check the Certificate that the intersitial uses for HTTPS. and since they, similar like a JWT only used signed public data, there's nothing a Man in the Middle could grab to gain control of the account. and since there is no typing involved, keylogging became utterly useless. and even the server of the respective sites dont have any data except for the respective clef-ID of the user, albeit that is different per application, so there is no way to connect a clef user between multiple sites solely based on their clef-ID.

Especially with its simplicity, Clef was a breakthrough for Multi-Factor and it's sad to see them go. so Let's compare 2 Factor Standards and how they fare.

first we have print out codes like TAN lists from your bank, long story short, these are Pretty much junk no matter from where you look at it.

Air Gap
someone could copy the list, make a photo or copy the list to steal everything at once without a trace.
they make phishing really simple since there's no time limit on the codes.
being a kind of blank signature would work okay-ish for logins but not for transaction security

next up, we have time based passwords like TOTP

with TOTP an open algorithm is available for anyone to implement and use them, although proprietary variations exist (e.g. Steamguard)
very limited in time, making real-time attacks needed.
need relatively synchronized Clocks between generator and verifier
depends on shared secret.
aside from time, a blank signature, so not good for transaction security.

then the direct counterpart to TOTP, are counterbased OTP, HOTP (H for HMAC, which is actually the base for TOTP but uses a counter instead of the time)

open algorithm, free for anyone to use, although proprietary variations exist
phishing not limited in time but old codes become invalid as soon as victim logs in (e.g. after realizing the mistake)
does not depend on an RTC, so no battery or similar needed
needs a relatively high tolerance to prevent counter desync by accidential increase of the counter -> many codes possible -> relatively simple bruteforce (6 digit code with 100 tolerace = 0,1% of getting in per try)
If the counter does desync, chaos will come, especially if both sides have no way to change the counter. (especially common with hardware token generators)
depends on shared secret.
aside from counter, a blank signature, so not good for transaction security.

Then there are (usually proprietary) ways of using both a counter and the time

being proprietary means the usage is limited.
Limited in time and old codes become invalid by logging in (e.g. after realizing the mistake)
depends on RTC and counter storage
now desync REALLY gets a problem, because there are 2 ways it can desync. decent sites and tokens should offer a way to get the counter and time data out of the token and enter the data to get the server to resync to the token.
depends on shared secret.
aside from time and counter, a blank signature, so not good for transaction security.

then we have a relatively new competitor in the game, U2F, aka the Universal Second Factor, which essentuially is a foolproof smartcard.

open standard, can be implemented relatively easy
relies on browser support
needs direct connection (USB, Bluetooth, NFC) to the acting client (not possible to use on very restricted clients
user has to aquire a U2F compatible hardware possible for under 10€)
requires Human interaction (e.g. pressing a button on the U2F Hardware) -> malware cannot trigger a U2F response
Each site gets a different U2F-Key, even from the same U2F-device, making it impossible to connect the user between sites solely upon the U2F.

we also have direct signature based solutions like SQRL, or of course clef, which will sadly go soon:

cryptographically a lot safer than a code generator like TOTP or HOTP
needs special software
if the software is available, it can run anywhere
cannot be air-gapped

Soft- and Hardware

Putting the Exact measure aside, there are hardware-based and software-based implementations for 2FA

Hardware based solutions:

cannot be copied
can not be read out without leaving traces
needs an extra piece of hardware
Air Gap

Software based solutions:

can be copied without a trace
can theoretically be accessed over any communication channel of the host device
doesnt need special hardware

With or without third Party

both can have its good and bad parts:

relying on 3rd party:

The 3rd party can check the connection of the user from another viewpoint, to possibly circumvent an MITM on the server-side
a bad or compromised 3rd party can do malicious logins on the site.
If 3rd party is down, the user might not be able to log in.
the user doesnt have to remember the account data of all sites.
a reasonably secured 3rd party account can be better than badly secured individual accounts.

no 3rd party involvement:

a successful MITM can do real damage
you dont need to trust anyone
you dont have to worry of a 3rd party provider going down

but you can get the best of both worlds using a 3rd party to validate that no junk happened but still checking everything yourself.

Final Words

Well the important question is, what to use.

The answer is, Hard to say. the most direct "opponent" to clef is SQRL, made by Security Researcher Steve Gibson at the Gibson Research Corporation (GRC), which differs from clef in 3 points:

SQRL uses a QR Code while clef uses a barcode
SQRL doesn't use a 3rd party
SQRL is an open algorithm.
SQRL has an Identity lock feature, meaning you can't just easily replace your SQRL key (you need a special key for that which should be stored offline)

so if you don't care about the True Login Feature of clef, SQRL is probably the best direct alternative because of the similarities.

if you dont need the "magical" part of clef, U2F would be your safest, bet, of course you also can go with the standard, TOTP.