> While there, this uses sha1. Is there some new specs about doing > it with sha256? Patching cyrus-sasl to add a new hashing algorithme > is just a one liner. This bit at least, would be a question to ask the cyrus-sasl folks. ;) Who have promised the project isn't dead.

Am Fri, 6 Nov 2015 08:55:34 +0000 schrieb Emmanuel Dreyfus <manu(a)netbsd.org&gt;: > Hello > > It seems OTP was broken at some time, I wonder if it is just me (and > why), or if it is more genral. I have a user with: > cmusaslsecretOTP: sha1 0499 se2124 xxxxxxxxxxxxxxxx > 00000000 > > slapd.conf contains: > access to dn.regex="^uid=.+,dc=example,dc=net$" attrs=cmusaslsecretOTP > by anonymous auth stop > by self write stop > by * none stop > > I try: > $ ldapwhomai -Y OTP -X dn:${user_dn} > SASL/OTP authentication started > (delay) > ldap_sasl_interactive_bind_s: Server is unavailable (52) > additional info: SASL(-8): transient failure (e.g., weak > key): simultaneous OTP authentications not permitted > > This is: > OpenLDAP 2.4.42 > Cyrusl SASL 2.1.26 If you are referring to sasl-OTP, which requires opiekey, this is still working, https://sys4.de/de/blog/2014/04/15/one-time-password-system-network-based... On the other hand, there is a Time based OTP module in contrib/slapd-modules/passwd/otpt which is broken, although i use google authenticator and alternatively sophos authenticator.

Am Sat, 7 Nov 2015 01:04:57 +0000 schrieb Howard Chu <hyc(a)symas.com&gt;: > Dieter Klünter wrote: > > Am Fri, 6 Nov 2015 08:55:34 +0000 > > schrieb Emmanuel Dreyfus <manu(a)netbsd.org&gt;: > > > >> Hello > >> > >> It seems OTP was broken at some time, I wonder if it is just me > >> (and why), or if it is more genral. I have a user with: > >> cmusaslsecretOTP: sha1 0499 se2124 xxxxxxxxxxxxxxxx > >> 00000000 > >> > >> slapd.conf contains: > >> access to dn.regex="^uid=.+,dc=example,dc=net$" > >> attrs=cmusaslsecretOTP by anonymous auth stop > >> by self write stop > >> by * none stop > >> > >> I try: > >> $ ldapwhomai -Y OTP -X dn:${user_dn} > >> SASL/OTP authentication started > >> (delay) > >> ldap_sasl_interactive_bind_s: Server is unavailable (52) > >> additional info: SASL(-8): transient failure (e.g., weak > >> key): simultaneous OTP authentications not permitted > >> > >> This is: > >> OpenLDAP 2.4.42 > >> Cyrusl SASL 2.1.26 > > > > If you are referring to sasl-OTP, which requires opiekey, this is > > still working, > > > > https://sys4.de/de/blog/2014/04/15/one-time-password-system-network-based... > > > > On the other hand, there is a Time based OTP module in > > contrib/slapd-modules/passwd/otpt which is broken, although i use > > google authenticator and alternatively sophos authenticator. > > The passwd/totp module is a slapd password-hash mechanism and has > nothing to do with SASL. It also works perfectly with google > authenticator, what makes you say it's broken? > I am not claiming the totp module to be a SASL Mechanism. 1. compiled pw-totp 2. installed pw-totp.la and pw-totp.so.0.0.0 3. included pw-totp.la in slapd.conf 4. added password-hash {TOTP1}

5. created a user dn: cn=test1 example,o=Test sn: example objectClass: inetOrgPerson cn: test1 example givenName: test1 6. added credentials by ldappasswd userPassword:: e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09 8. added credentials to google Authenticator and sophos authenticator 9. run ./ldapwhoami -D "cn=test1 example,o=Test" -W -H ldap://localhost:9007 10. entered the numberstring from a authenticator 11. result: ldap_bind: Invalid credentials (49)

You may test yourself, based on my credentials.

6. added credentials by ldappasswd userPassword:: e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09

>> 'e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09'.decode('base64')

>> s='NBUEI6KEJMYDCNBTGI2TMQKCINCA===='.decode('base64') >> len(s)

Dieter Klünter wrote: > 6. added credentials by ldappasswd > userPassword:: > e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09 I have not really tried the module myself yet but I note that the key is actually 21 bytes long (see below). Shouldn't that be 20 bytes? Ciao, Michael. Python 2.7.10 (default, May 24 2015, 14:46:10) [GCC] on linux2 >>> 'e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09'.decode('base64') '{TOTP1}NBUEI6KEJMYDCNBTGI2TMQKCINCA====' >>> s='NBUEI6KEJMYDCNBTGI2TMQKCINCA===='.decode('base64') >>> len(s) 21

Dieter Klünter wrote: > Am Sat, 7 Nov 2015 14:33:22 +0100 > schrieb Michael Ströder <michael(a)stroeder.com&gt;: > >> Dieter Klünter wrote: >>> 6. added credentials by ldappasswd >>> userPassword:: >>> e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09 >> >> I have not really tried the module myself yet but I note that the >> key is actually 21 bytes long (see below). Shouldn't that be 20 >> bytes? >> >> Python 2.7.10 (default, May 24 2015, 14:46:10) [GCC] on linux2 >>>>> 'e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09'.decode('base64') >> '{TOTP1}NBUEI6KEJMYDCNBTGI2TMQKCINCA====' >>>>> s='NBUEI6KEJMYDCNBTGI2TMQKCINCA===='.decode('base64') >>>>> len(s) >> 21 > > The TOTP1 string is base32 encoded, not base64. If it's sent to the Google Authenticator the base32-encoded form is appended to the totp:// URL. And looking at slapd-totp.c it seems you're also right regarding the storage format in 'userPassword': /* Key is stored in base32 */ But still 17 bytes look strange to me: Python 2.7.10 (default, May 24 2015, 14:46:10) [GCC] on linux2 >>> import base64 >>> base64.b32decode('NBUEI6KEJMYDCNBTGI2TMQKCINCA====') 'hhDyDK0143256ABCD' >>> len(base64.b32decode('NBUEI6KEJMYDCNBTGI2TMQKCINCA====')) 17 What's the correct length of your shared secret?

> $ ldapwhomai -Y OTP -X dn:${user_dn}