7 ms·

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

89 points by brna-2 8mo ago

brna-2 8mo ago
This is an early experiment in human-computable TOTP. Not production crypto, but a serious attempt to reach reasonable security for plausible 2FA. Protocol revisions, criticism, and contributions are welcome.
- ramon156 8mo ago
  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.
  - leothetechguy 8mo ago
    The security advantage I see in mtotp is that you never reveal the password to the system you are authenticating with, but that there is also no electronic device that can be compromised
- deleted 8mo ago
  [deleted]
- shaftway 8mo ago
  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.
vbarrielle 8mo ago
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.
- ulrikrasmussen 8mo ago
  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.
  - charcircuit 8mo ago
    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.
    - ulrikrasmussen 8mo ago
      Yes, that is certainly a more secure second factor since there are fewer ways for an attacker to steal it, but I don't think that should be a necessary condition for it to be called a second factor at all.
      - charcircuit 8mo ago
        I'm specifically talking about the "something you own" second factor. There are other factors which could be used as a second factor.
barbegal 8mo ago
An interesting idea but in theory just three correct pass codes and some brute force will reveal the secret key so you'd have to be very careful about only inputting the pass code to sites that you trust well. It's definitely computable on a piece of paper and reasonably secure against replay attacks.
- brna-2 8mo ago
  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.
  - i-con 8mo ago
    I'm not an expert, but roughly know the numbers. Usually with password-based key derivation, one would increase resource needs (processor time, memory demand) to counter brute forcing. Not an option for a human brain, I guess. So the key would have to be longer. And random or a lot longer. Over 80 random bits is generally a good idea. That's roughly 24 decimal digits (random!). I guess about 16 alphanumerical characters would do to, again random. Or a very long passphrase. So either remember long, random strings or doing a lot more math. I think it's doable but really not convenient.
    - thfuran 8mo ago
      A handful of words is generally more memorizable than the same number of bits as a random alphanumeric string. You wouldn’t need a very long pass phrase for 80 bits as long as you’re using a large dictionary.
- MattPalmer1086 8mo ago
  I was wondering about the overall security. How did you determine that 3 pass codes and brute force will reveal the secret key?
crote 8mo ago
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 that's how it is supposed to work. Does your mTOTP prove you own the single copy? No, you could trivially tell someone else the secret key. Does it prove that you currently own it? No, you can pre-calculate a verification token for future use. I still think it is a very neat idea on paper, but I'm not quite seeing the added value. The obvious next step is to do all the math in client-side code and just have the user enter the secret - doing this kind of mental math every time you log in is something only the most hardcore nerds get excited about.
- brna-2 8mo ago
  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.
- ulrikrasmussen 8mo ago
  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.
  - swiftcoder 8mo ago
    > Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen The only difference here is that you are hashing the password in your head, instead of trusting the client to hash it for you before submitting it to the server. Which makes the threat model here what, exactly? Keyloggers, or login pages that use outdated/insecure methods to authenticate with the server?
swiftcoder 8mo ago
Isn't this just manually hashing a password with a timed-salt? I don't see how this relates to TOTP
- ulrikrasmussen 8mo ago
  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.
  - swiftcoder 8mo ago
    > 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).
    - ulrikrasmussen 8mo ago
      No, the defining characteristic of a password is also how it is used: it is communicated in the clear to the verifier, thus revealing it to eavesdroppers. It is highly non-trivial to clone the knowledge in someone's brain if they never openly communicate the mTOTP secret but only do the computations in their head.
      - crote 8mo ago
        Not true. There are lots of authentication schemes where the plaintext password is never communicated. This becomes rather crucial when the client doesn't know for sure yet what the identity of the other side is. See for example wifi encryption. Cloning the knowledge in someone's brain is fairly easy. You just need a wrench.
        ulrikrasmussen 8mo ago
cuckovic 8mo ago
Really nice idea
MattPalmer1086 8mo ago
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.
- brna-2 8mo ago
  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.
  - MattPalmer1086 8mo ago
    Probably not needed. The computation of the code is not computationally expensive (human computation is a requirement) so no real impact on server having to perform the full computation. I guess if implemented client side it might provide a sanity check for the user before submitting, but it's more work for the human and they are almost as likely to get the checksum calculation wrong as any other part of it. So I would probably remove it.
- gildenFish 8mo ago
  It probably isn't for security, it is more likely a quick check that the code that you memorized makes sense.
- zzo38computer 8mo ago
  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.)
onion2k 8mo ago
I don't think people plan what time to log into things.
- brna-2 8mo ago
  Yep, they did not need to when the calculation was done in real time on a mobile phone. :D
deafpolygon 8mo ago
I see 2FA is often misunderstood by people. The basic premise with 2FA is that you combine “something you know” with “something you have”. You are already part of the 2FA — you’re the first factor: “something you know”. The second factor: “something you have” — often a personal device, or an object. This is ideally something no one else can be in possession of at the same time as you are.
- sigio 8mo ago
  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.
- deleted 8mo ago
  [deleted]
eisbaw 8mo ago
or we could use asymmetric biometric fingerprints. Turns out features can be extracted into public and private sets, and both are required for a match. I hold a patent on it btw
- crote 8mo ago
  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.
  - fc417fc802 8mo ago
    Biometrics are "something you are" but they are not a good substitute for either "something you have" or "something you know". My concern with them nearly always comes down to privacy. They are far too easy to abuse for collecting and selling user data. There are probably ways around that but how much will you ever be able to trust an opaque black box that pinky promises to irreversibly and uniquely hash your biometric data? It's an issue of trust and transparency.
pona-a 8mo ago
Yes! I've been thinking about a similar idea in October, using a "keyed hash" of the challenge computed with playing cards. I have no idea how secure this is, but the concept itself is exciting: the mental labor might function as a useful anti-coercion/fishing tool.
wolvoleo 8mo ago
Interesting idea but I don't think my users will grok this :) The worst thing about it is that people will go like "uuuh naaaah" and will just grab a random app off the play store and put their code in it. Now you are leaking secrets to whatever random app they use.
EPWN3D 8mo ago
If you can be tied to a chair and beaten with a rubber hose until you produce the token, it's just a password, albeit one that rotates. TOTP works because you have to possess the secure device at the time you're authenticating. If you don't have the device, then no amount of time with the rubber hose can make you cough up the required token.
jrm4 8mo ago
So, in my head, once I heard the idea, I started thinking of something WAY different, and maybe its worth considering. I was thinking something like a combination "security question," "captcha" and "secondary identifier" (whatever the thing that google et al do when they tell you to match the picture on your phone to complete the login) I don't know, something like "name the fruits that correspond to your first school colors" or similar
- mindslight 8mo ago
  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!
  - throwaway132448 8mo ago
    Unfortunately security theatre is viral, and nobody gets paid saying we should have less of it.
  - jrm4 8mo ago
    As op, yeah I'm actually with you on this. And at the very least, 2FA should be a much more "openly open standard." Which is to say, just do TOTP everywhere, let people have their initial generating key and be done with it. I generate mine from my computer when I can, but I'm surrounded by all this magic that implies that something different is going on, e.g. the Duo system which I'm forced to use by my job and doesn't make this sort of thing easy, if possible at all.
perching_aix 8mo ago
I've been pondering about something like this for a while, nice to see someone who didn't give up after seeing how demanding actual crypto is, like I did. I now wonder if it's possible to store a random value in one's head without it being eavesdroppable. Humans don't really do random, but it's essential for auth.
yoavsha1 8mo ago
Why base this on time? Using a simple HOTP which uses a rolling index for the "time value" seems like a much better choice for humans
istillwritecode 8mo ago
No. I'm comfortable remembering passwords.
- tatersolid 8mo ago
  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.
kazinator 8mo ago
Only if I'm not useful for 2FA when dead (taking away some incentive from killing me to get to the 2FA) and the functionality isn't tied to some part of my body that can be severed by bad actors (taking away the incentive to mutilate me to get to the 2FA).
polishdude20 8mo ago
I honestly thought this was about implantable subcutaneous chips at first read.

89 points by brna-2 8mo ago

This is an early experiment in human-computable TOTP. Not production crypto, but a serious attempt to reach reasonable security for plausible 2FA. Protocol revisions, criticism, and contributions are welcome.

ramon156 8mo ago
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.
- leothetechguy 8mo ago
  The security advantage I see in mtotp is that you never reveal the password to the system you are authenticating with, but that there is also no electronic device that can be compromised
deleted 8mo ago
[deleted]
shaftway 8mo ago
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.

vbarrielle 8mo ago

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.

ulrikrasmussen 8mo ago
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.
- charcircuit 8mo ago
  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.
  - ulrikrasmussen 8mo ago
    Yes, that is certainly a more secure second factor since there are fewer ways for an attacker to steal it, but I don't think that should be a necessary condition for it to be called a second factor at all.
    - charcircuit 8mo ago
      I'm specifically talking about the "something you own" second factor. There are other factors which could be used as a second factor.

barbegal 8mo ago

An interesting idea but in theory just three correct pass codes and some brute force will reveal the secret key so you'd have to be very careful about only inputting the pass code to sites that you trust well. It's definitely computable on a piece of paper and reasonably secure against replay attacks.

brna-2 8mo ago
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.
- i-con 8mo ago
  I'm not an expert, but roughly know the numbers. Usually with password-based key derivation, one would increase resource needs (processor time, memory demand) to counter brute forcing. Not an option for a human brain, I guess. So the key would have to be longer. And random or a lot longer. Over 80 random bits is generally a good idea. That's roughly 24 decimal digits (random!). I guess about 16 alphanumerical characters would do to, again random. Or a very long passphrase. So either remember long, random strings or doing a lot more math. I think it's doable but really not convenient.
  - thfuran 8mo ago
    A handful of words is generally more memorizable than the same number of bits as a random alphanumeric string. You wouldn’t need a very long pass phrase for 80 bits as long as you’re using a large dictionary.
MattPalmer1086 8mo ago
I was wondering about the overall security. How did you determine that 3 pass codes and brute force will reveal the secret key?

crote 8mo ago

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 that's how it is supposed to work. Does your mTOTP prove you own the single copy? No, you could trivially tell someone else the secret key. Does it prove that you currently own it? No, you can pre-calculate a verification token for future use. I still think it is a very neat idea on paper, but I'm not quite seeing the added value. The obvious next step is to do all the math in client-side code and just have the user enter the secret - doing this kind of mental math every time you log in is something only the most hardcore nerds get excited about.

brna-2 8mo ago
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.
ulrikrasmussen 8mo ago
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.
- swiftcoder 8mo ago
  > Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen The only difference here is that you are hashing the password in your head, instead of trusting the client to hash it for you before submitting it to the server. Which makes the threat model here what, exactly? Keyloggers, or login pages that use outdated/insecure methods to authenticate with the server?

swiftcoder 8mo ago

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

ulrikrasmussen 8mo ago
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.
- swiftcoder 8mo ago
  > 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).
  - ulrikrasmussen 8mo ago
    No, the defining characteristic of a password is also how it is used: it is communicated in the clear to the verifier, thus revealing it to eavesdroppers. It is highly non-trivial to clone the knowledge in someone's brain if they never openly communicate the mTOTP secret but only do the computations in their head.
    - crote 8mo ago
      Not true. There are lots of authentication schemes where the plaintext password is never communicated. This becomes rather crucial when the client doesn't know for sure yet what the identity of the other side is. See for example wifi encryption. Cloning the knowledge in someone's brain is fairly easy. You just need a wrench.
      - ulrikrasmussen 8mo ago

cuckovic 8mo ago

Really nice idea

MattPalmer1086 8mo ago

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.

brna-2 8mo ago
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.
- MattPalmer1086 8mo ago
  Probably not needed. The computation of the code is not computationally expensive (human computation is a requirement) so no real impact on server having to perform the full computation. I guess if implemented client side it might provide a sanity check for the user before submitting, but it's more work for the human and they are almost as likely to get the checksum calculation wrong as any other part of it. So I would probably remove it.
gildenFish 8mo ago
It probably isn't for security, it is more likely a quick check that the code that you memorized makes sense.
zzo38computer 8mo ago
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.)

onion2k 8mo ago

I don't think people plan what time to log into things.

brna-2 8mo ago
Yep, they did not need to when the calculation was done in real time on a mobile phone. :D

deafpolygon 8mo ago

I see 2FA is often misunderstood by people. The basic premise with 2FA is that you combine “something you know” with “something you have”. You are already part of the 2FA — you’re the first factor: “something you know”. The second factor: “something you have” — often a personal device, or an object. This is ideally something no one else can be in possession of at the same time as you are.

sigio 8mo ago
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.
deleted 8mo ago
[deleted]

eisbaw 8mo ago

or we could use asymmetric biometric fingerprints. Turns out features can be extracted into public and private sets, and both are required for a match. I hold a patent on it btw

crote 8mo ago
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.
- fc417fc802 8mo ago
  Biometrics are "something you are" but they are not a good substitute for either "something you have" or "something you know". My concern with them nearly always comes down to privacy. They are far too easy to abuse for collecting and selling user data. There are probably ways around that but how much will you ever be able to trust an opaque black box that pinky promises to irreversibly and uniquely hash your biometric data? It's an issue of trust and transparency.

pona-a 8mo ago

Yes! I've been thinking about a similar idea in October, using a "keyed hash" of the challenge computed with playing cards. I have no idea how secure this is, but the concept itself is exciting: the mental labor might function as a useful anti-coercion/fishing tool.

wolvoleo 8mo ago

Interesting idea but I don't think my users will grok this :) The worst thing about it is that people will go like "uuuh naaaah" and will just grab a random app off the play store and put their code in it. Now you are leaking secrets to whatever random app they use.

EPWN3D 8mo ago

If you can be tied to a chair and beaten with a rubber hose until you produce the token, it's just a password, albeit one that rotates. TOTP works because you have to possess the secure device at the time you're authenticating. If you don't have the device, then no amount of time with the rubber hose can make you cough up the required token.

jrm4 8mo ago

So, in my head, once I heard the idea, I started thinking of something WAY different, and maybe its worth considering. I was thinking something like a combination "security question," "captcha" and "secondary identifier" (whatever the thing that google et al do when they tell you to match the picture on your phone to complete the login) I don't know, something like "name the fruits that correspond to your first school colors" or similar

mindslight 8mo ago
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!
- throwaway132448 8mo ago
  Unfortunately security theatre is viral, and nobody gets paid saying we should have less of it.
- jrm4 8mo ago
  As op, yeah I'm actually with you on this. And at the very least, 2FA should be a much more "openly open standard." Which is to say, just do TOTP everywhere, let people have their initial generating key and be done with it. I generate mine from my computer when I can, but I'm surrounded by all this magic that implies that something different is going on, e.g. the Duo system which I'm forced to use by my job and doesn't make this sort of thing easy, if possible at all.

perching_aix 8mo ago

I've been pondering about something like this for a while, nice to see someone who didn't give up after seeing how demanding actual crypto is, like I did. I now wonder if it's possible to store a random value in one's head without it being eavesdroppable. Humans don't really do random, but it's essential for auth.

yoavsha1 8mo ago

Why base this on time? Using a simple HOTP which uses a rolling index for the "time value" seems like a much better choice for humans

istillwritecode 8mo ago

No. I'm comfortable remembering passwords.

tatersolid 8mo ago
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.

kazinator 8mo ago

Only if I'm not useful for 2FA when dead (taking away some incentive from killing me to get to the 2FA) and the functionality isn't tied to some part of my body that can be severed by bad actors (taking away the incentive to mutilate me to get to the 2FA).

polishdude20 8mo ago

I honestly thought this was about implantable subcutaneous chips at first read.