https://bugs.openldap.org/show_bug.cgi?id=10192
Issue ID: 10192 Summary: otp.c overlay - HOTP wrongly numbers gneration Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: michal.pura@gmail.com Target Milestone: ---
Hello, I am trying to use otp.c overlay but seems that numbers are not properly generated.
In my case I have random secret like 'aaaabbbbccccdddd' and according to what Google Authenticator and https://www.verifyr.com/en/otp/check#hotp is generating we should have the following HOTP codes for above secret:
1 - 229789 2 - 801677 3 - 630108 4 - 214543 5 - 916392 6 - 346078 7 - 701644 8 - 865071 9 - 431248 10 - 355053
but, otp.c module is returning the following numbers:
1 - 441008 2 - 465617 3 - 669281 4 - 042697 5 - 461210 6 - 620979 7 - 700859 8 - 573924 9 - 805067 10 - 135880
The secret is properly generated and used in the code. I've checked it under debugger. The hash algorithm is defined as 1.2.840.113549.2.7 -> HMAC-WITH-SHA1. What is wrong?
https://bugs.openldap.org/show_bug.cgi?id=10192
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu hyc@openldap.org --- The OpenLDAP code is correct. Your example is invalid, it only has a 16 character secret but a SHA1 secret is 20 bytes.
https://bugs.openldap.org/show_bug.cgi?id=10192
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #2 from michal.pura@gmail.com --- This is the raw secret before SHA1 encoding. Does it mean that secret which is stored in "oathSecret" attribute should be stored in encoded SHA1 form?
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #3 from Howard Chu hyc@openldap.org --- Note: the web form you referenced takes the shared secret in base32 encoded form, but, as documented in the slapo-otp(5) manpage, the oathSecret attribute stores the secret as raw bytes. So you can't just paste the secret from one to the other and expect to get matching values.
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #4 from michal.pura@gmail.com --- This I know. Wondering if compiling openldap for Windows could cause some differences in terms of otp.c module?
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #5 from michal.pura@gmail.com --- As for the following settings which are the same as in hotp.ldif example:
dn: ou=Users,dc=test,dc=int oathHMACAlgorithm: 1.2.840.113549.2.7 oathHOTPLookAhead: 3
dn: uid=Arman,ou=Users,dc=test,dc=int oathHOTPCounter: 1 oathSecret: PcbKpIJKbSiHZ7IzHiC0MWbLhdk= oathHOTPParams: ou=Users,dc=test,dc=int
expected HOTP tokens are (test080-hotp):
TOKEN_0=818800 TOKEN_1=320382 TOKEN_2=404533 TOKEN_3=127122 TOKEN_4=892599 TOKEN_5=407030 TOKEN_6=880935 TOKEN_7=920291 TOKEN_8=145192 TOKEN_9=316404 TOKEN_10=409144
but in my case the tokens are like these: TOKEN_0 - 192008 TOKEN_1 - 057719 TOKEN_2 - 547141 TOKEN_3 - 369878 TOKEN_4 - 225285 TOKEN_5 - 963571 TOKEN_6 - 130275 TOKEN_7 - 469460 TOKEN_8 - 496738 TOKEN_9 - 097212 TOKEN_10 - 086214
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #6 from michal.pura@gmail.com --- The HOTP tokens generated in Google Authenticator with the secret configured manually (the same as in the test example) gives the following results:
1 - 184463 2- 450997 3- 875981 4 - 916697 5 - 758951 6 - 341697 7 - 959941 8 - 950943 9 - 103548 10 - 321898
So, now I don't understand totally from where the expected test values were taken.
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #7 from Howard Chu hyc@openldap.org --- (In reply to michal.pura from comment #6)
The HOTP tokens generated in Google Authenticator with the secret configured manually (the same as in the test example) gives the following results:
1 - 184463 2- 450997 3- 875981 4 - 916697 5 - 758951 6 - 341697 7 - 959941 8 - 950943 9 - 103548 10 - 321898
So, now I don't understand totally from where the expected test values were taken.
That is all incorrect. The test example's secret key is 3d c6 ca a4 82 4a 6d 28 87 67 b2 33 1e 20 b4 31 66 cb 85 d9
The base32 encoding of this is HXDMVJECJJWSRB3HWIZR4IFUGFTMXBOZ which produces the codes in the test080 script, as you can see on the verifyr web site.
There is no OpenLDAP bug here. If you want to ask for more help about hotp use the openldap-technical mailing list. This ticket is closed.
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #8 from michal.pura@gmail.com --- In my opinion example given in test080-hotp which uses PcbKpIJKbSiHZ7IzHiC0MWbLhdk= as a secret is misleading.
PcbKpIJKbSiHZ7IzHiC0MWbLhdk= is base64 encoded value of 3d c6 ca a4 82 4a 6d 28 87 67 b2 33 1e 20 b4 31 66 cb 85 d9 which is pointed by you recently.
The problem is that expected HOTP values which are embedded in the tests are not correct because openldap treat this secret PcbKpIJKbSiHZ7IzHiC0MWbLhdk= as a raw value directly (no base64 decoding is done before) which is the key point here.
This means that the secret is PcbKpIJKbSiHZ7IzHiC0MWbLhdk= NOT 3d c6 ca a4 82 4a 6d 28 87 67 b2 33 1e 20 b4 31 66 cb 85 d9.
Google Authenticator or www.verifyr.com require base32 encoded secret, so the secret which should be given there is KBRWES3QJFFEWYSTNFEFUN2JPJEGSQZQJVLWETDIMRVT2===.
So, expected values in the tests should different. Proper values are presented below:
TOKEN_0 - 192008 TOKEN_1 - 057719 TOKEN_2 - 547141 TOKEN_3 - 369878 TOKEN_4 - 225285 TOKEN_5 - 963571 TOKEN_6 - 130275 TOKEN_7 - 469460 TOKEN_8 - 496738 TOKEN_9 - 097212 TOKEN_10 - 086214
MP.
https://bugs.openldap.org/show_bug.cgi?id=10192
--- Comment #9 from Howard Chu hyc@openldap.org --- (In reply to michal.pura from comment #8)
In my opinion example given in test080-hotp which uses PcbKpIJKbSiHZ7IzHiC0MWbLhdk= as a secret is misleading.
PcbKpIJKbSiHZ7IzHiC0MWbLhdk= is base64 encoded value of 3d c6 ca a4 82 4a 6d 28 87 67 b2 33 1e 20 b4 31 66 cb 85 d9 which is pointed by you recently.
The problem is that expected HOTP values which are embedded in the tests are not correct because openldap treat this secret PcbKpIJKbSiHZ7IzHiC0MWbLhdk= as a raw value directly (no base64 decoding is done before) which is the key point here.
NO, wrong. You have no idea what you're talking about. OpenLDAP stores the raw value. The base64 encoding is only used for display in LDIF, that's what the double-colon means.
Use the mailing list for discussion., there is no bug here. The code works as designed, according to the RFCs. Whatever problems you're having, the OpenLDAP code is 100% correct.
Follow directions and use the mailing list, or be banned. Your choice.
-
openldap-its＠openldap.org