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
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.
--On Friday, November 06, 2015 8:55 AM +0000 Emmanuel Dreyfus manu@netbsd.org wrote:
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.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com wrote:
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.
I will submit my patch once I will have OTP working again with OpenLDAP: I cannot test anything right now.
Am Fri, 6 Nov 2015 08:55:34 +0000 schrieb Emmanuel Dreyfus manu@netbsd.org:
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-se...
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.
-Dieter
Dieter Klünter wrote:
Am Fri, 6 Nov 2015 08:55:34 +0000 schrieb Emmanuel Dreyfus manu@netbsd.org:
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-se...
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?
Am Sat, 7 Nov 2015 01:04:57 +0000 schrieb Howard Chu hyc@symas.com:
Dieter Klünter wrote:
Am Fri, 6 Nov 2015 08:55:34 +0000 schrieb Emmanuel Dreyfus manu@netbsd.org:
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-se...
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.
-Dieter
Am Sat, 7 Nov 2015 13:29:25 +0100 schrieb Dieter Klünter dieter@dkluenter.de:
Am Sat, 7 Nov 2015 01:04:57 +0000 schrieb Howard Chu hyc@symas.com:
Dieter Klünter wrote:
Am Fri, 6 Nov 2015 08:55:34 +0000 schrieb Emmanuel Dreyfus manu@netbsd.org:
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-se...
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.
- compiled pw-totp
- installed pw-totp.la and pw-totp.so.0.0.0
- included pw-totp.la in slapd.conf
- added password-hash {TOTP1}
4.1 forgot to mention that i have added a overlay declaration overlay totp which happens to be the first overlay, followed by memberOf
- created a user
dn: cn=test1 example,o=Test sn: example objectClass: inetOrgPerson cn: test1 example givenName: test1
- added credentials by ldappasswd userPassword:: e1RPVFAxfU5CVUVJNktFSk1ZRENOQlRHSTJUTVFLQ0lOQ0E9PT09
- added credentials to google Authenticator and sophos authenticator
- run ./ldapwhoami -D "cn=test1 example,o=Test" -W -H ldap://localhost:9007
- entered the numberstring from a authenticator
- result: ldap_bind: Invalid credentials (49)
You may test yourself, based on my credentials.
Hi,
On Saturday, 7. November 2015 13:45:21 Dieter Klünter wrote:
schrieb Howard Chu hyc@symas.com:
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 concur with Harald. the pw-totp module in HEAD works.
There have been issues in the initial commit, which have been fixed since then.
Best Peter
Dieter Klünter wrote:
- 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
Michael Ströder wrote:
Dieter Klünter wrote:
- 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?
Looks like you're right. Perhaps we should re-enable the key length checks in the module (which are currently disabled with #if 0 ).
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
Am Sat, 7 Nov 2015 14:33:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
- 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
The TOTP1 string is base32 encoded, not base64. With regard to length, this might be a bug in google Authenticator, as it would not accept a credential string shorter than mine.
-Dieter
Dieter Klünter wrote:
Am Sat, 7 Nov 2015 14:33:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
- 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?
Ciao, Michael.
Am Sat, 7 Nov 2015 22:03:04 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
Am Sat, 7 Nov 2015 14:33:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
- 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?
In fact i have tested with various length. You are correct that the key is question is of 17 bytes.
-Dieter
Am Sat, 7 Nov 2015 20:53:38 +0100 schrieb Dieter Klünter dieter@dkluenter.de:
Am Sat, 7 Nov 2015 14:33:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
- 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
The TOTP1 string is base32 encoded, not base64. With regard to length, this might be a bug in google Authenticator, as it would not accept a credential string shorter than mine.
Just for the records: the pw-totp has not a bug. The so called SMART devices are not smart at all. I expected them to convert user password to a base32 string, which they don't. To produce a totp numberstring, the valid base32 string has to be entered to the smart device application. I have successfully tested it with google authenticator, Sophos authenticator and FreeOTP.
-Dieter
Dieter Klünter wrote:
$ ldapwhomai -Y OTP -X dn:${user_dn}
The main problem with SASL/OTP is that clients have to implement special support for it.
There will be a talk about OATH-LDAP at LDAPcon 2015:
http://ldapcon.org/2015/?page_id=185
Similar to password/totp it also works for LDAP simple bind but with some policy parameters enforced.
Ciao, Michael.
Emmanuel Dreyfus manu@netbsd.org wrote:
$ 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
I made some progress, with a fix in cyrus SASL (I also include my added SHA2 support just in case someone has a comment on it).
This was a signedness problem in the timeout parameter: readed as signed on a machines with 32 bits time_t, it get always in a far future. Scanning it as unsigned fixes the problem.
--- plugins/otp.c.orig 2012-10-12 16:05:48.000000000 +0200 +++ plugins/otp.c 2015-11-07 15:19:43.000000000 +0100 @@ -92,8 +92,12 @@ static algorithm_option_t algorithm_options[] = { {"md4", 0, "md4"}, {"md5", 0, "md5"}, {"sha1", 4, "sha1"}, + {"sha224", 4, "sha224"}, + {"sha256", 4, "sha256"}, + {"sha384", 4, "sha384"}, + {"sha512", 4, "sha512"}, {NULL, 0, NULL} };
/* Convert the binary data into ASCII hex */ @@ -675,9 +679,9 @@ SETERROR(utils, "OTP secret too short"); return SASL_FAIL; }
- sscanf(secret, "%s\t%04d\t%s\t%s\t%020ld", + sscanf(secret, "%s\t%04d\t%s\t%s\t%020lu", alg, seq, seed, buf, timeout);
hex2bin(buf, otp, OTP_HASH_SIZE);
openldap-technical@openldap.org
-
Dieter Klünter -
Emmanuel Dreyfus -
Howard Chu -
manu＠netbsd.org
-
Michael Ströder -
Peter Marschall -
Quanah Gibson-Mount