9front - general discussion about 9front
 help / color / mirror / Atom feed
From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front] Totp in factotum
Date: Fri, 17 Mar 2023 17:43:26 +0100 (GMT+01:00)	[thread overview]
Message-ID: <9544fd2c-2389-456e-a076-8fd7a4b5ce4e@sirjofri.de> (raw)
In-Reply-To: <C9FF62480A9B0C558D2F16A7FC133B81@felloff.net>


17.03.2023 10:49:46 cinap_lenrek@felloff.net:

> so the key is base32 encoded binary, but the code
> uses strlen() on the binary output?

You're right, I shouldn't assume the key to be plain text since it can be binary (and probably is). I only tested with "known and easy to type" secrets so far.

> the rfc uses hex encoding, not sure what is
> used in practice. the issue with base32 is
> that there are many different alphabets
> for it. it is not as standartized as
> base64.

Yeah, I'd personally also probably use base64, but in practice the key exchange uses base32 (with the set we have in the standard implementation currently). With key exchange I mean, the encoded url you usually see as a QR code as well as the secret number below that (something like otpauth://). I tested it with microsoft authenticator and it worked in my tests.

I also assume (for the client protocol) that the user gets the code like that, base32 encoded. But I can double check on common sites how they encode it. Maybe it's hex and the base32 is only for the qr code, though I'd doubt that.

> this looks extreamly fishy and wrong. what if
> the binary secret contains nuls? how's the secret
> generated? rfc6238 says it should be random
> binary.

In this case I didn't think about factotum being responsible for generating the secret, only for storing it and using it. Should I assume that factotum also generates secrets itself? That would also only make sense for the server protocol, since the client protocol is for generating OTPs for authenticating the user to external services, like common authenticator apps.

> so i think the functions needs to take a uchar*
> for the key and a key-length field, which you
> get from dec32() return value.

I guess I need a heads up there. When decoding the base32 encoded binary data, how would I know how many bytes I need? Should I just assume that a buffer of length 1024 is enough, or count on dec32 to give me a result and allocate more memory if I need it?

For compatibility, does it make sense to write my own enc32 encoding function, just in case the default changes?

Thanks for your response, I'll further improve it.

sirjofri

  reply	other threads:[~2023-03-17 16:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 19:08 [9front] Totp in factotum (advice and code) sirjofri
2023-03-16 19:51 ` [9front] Totp in factotum sirjofri
2023-03-17  9:48   ` cinap_lenrek
2023-03-17 16:43     ` sirjofri [this message]
2023-03-18  1:42       ` cinap_lenrek
2023-03-21 20:10 ` [9front] Re: Totp in factotum (advice and code) sirjofri
2023-04-05  7:08   ` sirjofri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9544fd2c-2389-456e-a076-8fd7a4b5ce4e@sirjofri.de \
    --to=sirjofri+ml-9front@sirjofri.de \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).