From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22396 invoked from network); 17 Mar 2023 16:45:05 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 17 Mar 2023 16:45:05 -0000 Received: from sirjofri.de ([5.45.105.127]) by 9front; Fri Mar 17 12:43:34 -0400 2023 Received: from dummy.faircode.eu ([95.90.217.107]) by sirjofri.de; Fri Mar 17 17:43:26 +0100 2023 Date: Fri, 17 Mar 2023 17:43:26 +0100 (GMT+01:00) From: sirjofri To: 9front@9front.org Message-ID: <9544fd2c-2389-456e-a076-8fd7a4b5ce4e@sirjofri.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: <9544fd2c-2389-456e-a076-8fd7a4b5ce4e@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: compliant information-aware SQL over AJAX markup app Subject: Re: [9front] Totp in factotum Reply-To: 9front@9front.org Precedence: bulk 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