MTOTP: Wouldn't it be nice if you were the 2FA device?

TOTP is also just password + some computation. So where is the difference? There is a lot of security theatre around TOTP with the QR code and then need of an app but you can write a 8 liner in python that does the same when you extract the password out of the QR code.

   import base64
   import hmac
   import struct
   import time

   def totp(key, time_step=30, digits=6, digest='sha1'):
        key = base64.b32decode(key.upper() + '=' \* ((8 - len(key)) % 8))
        counter = struct.pack('>Q', int(time.time() / time_step))
        mac = hmac.new(key, counter, digest).digest()
        offset = mac[-1] & 0x0f
        binary = struct.unpack('>L', mac[offset:offset+4])[0] & 0x7fffffff
        return str(binary)[-digits:].zfill(digits)

In practice most TOTP implementation also do not prove that you have a device which is the sole owner of the secret. Except for proprietary app-based solutions the usual protocol is to display a QR code which just encodes the secret in plain text.

As long as you never enter the secret anywhere but only do the computation is your head, this is just using your brain as the second factor. I would not call this a password since it is not used in the same way. Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen. This proves that you are in possession of your brain.

> 2FA is "something you have" (or ".. you are", for biometrics): it is supposed to prove that you currently physically posses the single copy of a token. The textbook example is a TOTP stored in a Yubikey.

No, 2FA means authentication using 2 factors of the following 3 factors:

- What you know (eg password)

- What you have (eg physical token)

- What you are (eg biometrics)

You can "be the 2FA" without a token by combining a password (what you know) and biometrics (what you are). Eg, fingerprint reader + password, where you need both to login.

>The obvious next step is to do all the math in client-side code and just have the user enter the secret

https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

> this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers

I'm open to discovering I'm wrong here, but I have never understood this line of thinking. Assuming you 2fa into your password manager when you first sign in on your device, it's still 2 factors all the way down.

As you sign into your password manager, the "something you have" is your 2fa device that you use to sign into your password manager (which is obviously not being filled in by your password manager). Subsequent password manager unlocks which don't prompt for your token are still 2fa because the "something you have" is your computer with which you signed into your password manager.

Why is this a problem?

Time based skew makes it a changeable second factor, additional changeable pass makes it the second factor, Also - if the first factor is a password manager or ssh key - this is the second factor.

The idea of it was so neat to me, I just had to thinker with it.

I tend to agree that this doesn't really add a second factor. After all, both the mTOTP secret and the password are something you know, and something you could tell someone else.

However, I do think there is added value here, at least in principle: It increases the difficulty of credential stuffing attacks, which, IMHO is the main value of having a TOTP secret stored in one or more password managers.

"Regular" TOTP stored in a password manager also helps with password reuse when a site is compromised because each site has a different TOTP secret. It seems implausible that a user could remember a different mTOTP secret for each site.

The single copy part would be a lot more common if it was widely supported to have multiple tokens registered to an account.

And the main point (though I agree that it doesn't make it 2FA), is to not have the secret be disclosed when you prove that you have it, which is what TOTP also achieves, which makes phishing or sniffing it significantly less valuable.

I don't think OP claimed it adds value.

> It explores the limits of time-based authentication under strict human constraints and makes no claims of cryptographic equivalence to standard TOTP.

I think they're just having fun.

misunderstanding of 2FA annoys me.

Like, banking site requiring phone's 2FA (whether actual or SMS), okay, you have to know password and access to the device or at least a SIM card so 2 things need to be compromised. Computer vulnerable, no problem, phone vulerable, no problem, both need to be vulnerable to defeat it

...then someone decided to put banking on the second factor and now phone has both password and token (or access to SMS) to make a transaction, so whole system is one exploit away from defeat.

I was wondering about the overall security. How did you determine that 3 pass codes and brute force will reveal the secret key?

Yep, I am aware, 2 or 3 OTP's and timestamps plus some brute forcing using the source-code. Server-side brute force by input should or could be implausible. But that is why I am signaling here that I would love a genius or a playful expert/enthusiast contributing a bit or two to it - or becoming a co-author.

Except that for 99% of my passwords, I am 100% sure I do not, and never will, know them, they are 60-100+ bytes of random data, only known by my passwordmanager. The only thing I know, is the passphrase for my passwordmanager. TOTP codes are also stored in there, but I see it more as a replay-protection for captured passwords, though this is also really a non-issue in this time of almost no plaintext protocols.

I don't really get what tone you're doing for. Is this "a serious attempt", or is this "something that does not guarantee any cryptographic security"?

Nonetheless I do not see what issues 2FA has that this solves. Having the electronic device is the security. Without it there is no security.

The algorithm for the checksum (the sixth digit) is subject to one of the most common human errors, swapping adjacent digits. The UPC checksum algorithm handles this without significantly more complexity. They have you multiply all of the numbers in odd positions by 3 and then add up all numbers. The last digit is chosen to make the sum a multiple of 10.

To use your example: 51076, you'd do `5*3 + 1 + 0*3 + 7 + 6*3 = 15 + 1 + 0 + 7 + 18 = 41`. The sixth digit would be 9 ((10 - (41 mod 10)) mod 10). If you were to transpose any two adjacent numbers the checksum would be off. 3 is chosen because it's the smallest number that is co-prime with 10.

In that case nothing based on RFC 6838 would qualify as a second factor because nothing prevents you from just remembering the TOTP secret and compute the one-time code using a piece of JS. Or even putting it in your password manager.

I think it is too simple to reduce the definition of second factor to how it is stored. It is rather a question of what you need to log in. For TOTP the client has the freedom to choose any of (not exhaustive):

1. Remember password, put TOTP in an app on smartphone => Client has to remember password and be in possession of smartphone.

2. Put password and TOTP in password manager => Client has to remember the master password to the password manager and be in possession of the device on which it runs. Technically, you have to be in possession of just the encrypted bits making up the password database, but it is still a second factor separate from the master password.

Maybe some type of long physical probe you have to sit on and it generates a hash from the exact shape of your "cavity".

Seriously, am I the only one who was happier without any of this "2FA" crap? VPS/Domain/Google with a hardware token is the one narrow scope where I see any value, and even those I could do without. Every other site is just a non-consensual nagging that hassles me when logging in. Bank accounts are the worst, as every bit of friction for checking my balance/transactions actually decreases my security!

I remain very skeptical of fingerprints.

They are both too mutable (cuts and burns will alter them) and not mutable enough (you can't re-roll your fingerprints after a leak).

On top of that, you are also literally leaving them on everything you touch, making it trivial for anyone in your physical presence to steal them.

They are probably pretty decent for police use, but I don't believe they are a good replacement for current tech when it comes to remote auth.

I originally included it as a structural integrity digit, with the option for early rejection on the server side. That early exit check is not implemented in the current PAM module yet.

This is an early POC, and sanity checks like this are exactly the kind of feedback I’m looking for.

That is what I thought too, when I read it. (I was going to mention it if I did not find someone else already did.)

It probably isn't for security, it is more likely a quick check that the code that you memorized makes sense.

Yep, they did not need to when the calculation was done in real time on a mobile phone. :D

TOTP is also just hashing a password with a time salt. The purpose is just to prove that you are in possession of the device that stores the password without actually ever entering the password anywhere where it can be leaked. In this case the device is just your brain.

You’ve never had a concussion, gone under anesthesia, or gotten older? Memory based passwords are not durable; I personally forgot my Google account password after a surgery.