Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 116 posts

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

#21

Post by brna-2 »

MattPalmer1086 wrote: post #13

What is the purpose of the 6th digit? It doesnt add any security, as it is trivially computable from the other digits already computed. It appears to be a checksum, but I can't see why one would be needed.

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.

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

#23

Post by gildenFish »

MattPalmer1086 wrote: post #13

What is the purpose of the 6th digit? It doesnt add any security, as it is trivially computable from the other digits already computed. It appears to be a checksum, but I can't see why one would be needed.

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

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

#24

Post by fxj »

crote wrote: post #5

What makes this 2FA? It's "something you know, plus mental labor", which makes it a password. 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. Granted, this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers, but…

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)
https://dev.to/yusadolat/understanding-totp-what-really-happ...

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

#25

Post by josephg »

crote wrote: post #5

What makes this 2FA? It's "something you know, plus mental labor", which makes it a password. 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. Granted, this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers, but…

> 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.

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

#27

Post by fc417fc802 »

charcircuit wrote: post #16
ulrikrasmussen wrote: post #14

Earlier quoted context omitted.

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…

For proper 2nd factors the secret is a hardware key that practically can not be extracted so it is impossible for someone to know it. They must obtain the piece of hardware to use the key.

Can't say I agree with this take. Sure, something hardware bound is more secure under certain threat models. For others it's largely irrelevant. There are also drawbacks, such as not being able to back it up. That might or might not matter. "Just" get a second hardware token, register that as well, and store it somewhere safe won't always be a realistic (or perhaps desirable) option for everyone in every scenario. It certainly reduces your flexibility.

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

#28

Post by fc417fc802 »

ulrikrasmussen wrote: post #14
vbarrielle wrote: post #3

The idea is interesting, but I don't think this qualifies as a second factor, as it can be reduced to a factor you have to remember, so equivalent to a password. The second factor should be derived either from something you own, or something that can be obtained from biometry.

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…

> I think it is too simple to reduce the definition of second factor to how it is stored.

I think the defining characteristic is how it is used. I can use a password like a second factor, and I can use a TOTP code like a password. The service calls it a password or a second factor because that was the intention of the designer. But I can thwart those intentions if I so choose.

Recall the macabre observation that for some third factor implementations the "something you are" can quickly be turned into "something your attacker has".

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

#29

Post by swiftcoder »

ulrikrasmussen wrote: post #8
swiftcoder wrote: post #6

Isn't this just manually hashing a password with a timed-salt? I don't see how this relates to TOTP

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.

> In this case the device is just your brain

And that makes it a password (i.e. the primary factor, not a second factor). The whole point of a second factor is that it's not trivially cloneable (hence why, for example, SMS is a poor form of 2FA in the presence of widespread SIM cloning attacks).

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

#30

Post by crote »

fxj wrote: post #24
crote wrote: post #5

What makes this 2FA? It's "something you know, plus mental labor", which makes it a password. 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. Granted, this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers, but…

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() + '=' \*…

You are supposed to store the password in a Secure Enclave, which you can only query for the current token value. You are also supposed to immediately destroy the QR code after importing it.

As I already mentioned, the fact that people often use it wrong undermines its security, but that doesn't change the intended outcome.

Post reply on HN