Hi, Correcting myself...
>> Found an interesting caveat which should be addressed, I think. >> >> Our system (LinOTP) knows "PIN+OTP" or "PIN" as valid input, the >> latter leading to "send me a token by SMS/e-mail/...". >> >> If I press return at the challenge prompt, it seems the SCRV1: string >> is not formed the way the plugin wants it, and I end up with >> >> pass=SCRV1%3AMTE5NQ%3D%3D > > How to format this if response is empty is not clearly documented > but my impression was that the second ':' (%3A) is required. > > management-notes.txt specifies the format as > > password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>" > > The Windows GUI prints it using a template "SCRV1:%s:%s", so the second > colon will be present if response is empty -- if that's not happening > I would consider that a bug in the GUI. > > When password is read from stdin, its formatted as (from misc.c line 358) > > buf_printf(&packed_resp, "SCRV1:%s:%s", pw64, resp64); > > So that should also contain the second colon. However. just realized that my plugin patch assumes a non-empty password and response after base64 decode. Else it gives up on unpacking and treats it as a regular password. E.g., in auth-pamc.c (line 316) n = plugin_base64_decode(resp, up->response, sizeof(up->response)-1); if (n > 0) I think we could and should accept empty strings for both -- let's fix it. Selva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
