Also @MattPalmer1086 the best solution for this I have now is to have several secret keys and rotate usage. Would be nice to have some additional security boosts.

Key rotation among a set of keys only partially mitigates the issue (have to obtain more samples).

It has it's own synch problems (can you be sure which key to use next and did the server update the same as you, or did the last request not get through?).

This post on security stack exchange seems relevant.

https://security.stackexchange.com/questions/150168/one-time...

Yep known issue, was hoping someone could spice the protocol up without making it mentally to heavy, hn is full of smart playful people.

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

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.

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.

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

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.

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.

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.

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.

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

Starting out with the stable preset I had no idea how hard it would be to not make a object slingshot out. But it is a really fun sim, I think I will let my kid play with it.

Well that is not how I reed it, but: Every final state has an unique prompt. You could have several final states have the same unique prompt.

> You could have several final states have the same unique prompt.

They explicitly claim that the function is injective, that is, that each unique input produces a unique output.

I know ultimately I am not good nor bad, I am not an absolute. I am an agentic blob of meat, and with every decision I can choose any of the paths at my disposal, rewriting my story as I go. There is something I live by, though. My whole life I have observed in others the ideals that I came to admire or to hate, and I try to adhere to the ones I admire as often as I can, as I am pretty sure I would hate myself otherwise.