View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002212SOGoWeb Generalpublic2013-01-30 21:542013-02-04 19:04
Reporterhrichter Assigned Tojraby 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.0.4a 
Summary0002212: Users in LDAP with user+Password exceeding 41chars can't log into Web interface
Description

When users in my LDAP directory with passwords longer than 11 bytes try to log in via web interface, they do not get any message regarding password failure, a redirect is happening and then they end up on the logon page again, except the url has changed to
https://sogo.host.de/SOGo/so/user%40domain.de
After several serial logon attempts the login works, but this is definitely annoying.

Jan 29 23:06:46 sogod [15880]: <0x0x2ab99fd09948[NGLdapConnection]> Using ldap_init (deprecated) for LDAP host:port 127.0.0.1:389
Jan 29 23:06:46 sogod [15880]: <0x0x2ab99f141168[NGLdapConnection]> Using ldap_init (deprecated) for LDAP host:port 127.0.0.1:389
2013-01-29 23:06:46.740 sogod[15880] -[NGLdapConnection _searchAtBaseDN:qualifier:attributes:scope:]: search with at base filter for attrs `h
an 29 23:06:46 sogod [15880]: <0x0x2ab99fd09948[NGLdapConnection]> Using ldap_init (deprecated) for LDAP host:port 127.0.0.1:389
Jan 29 23:06:46 sogod [15880]: SOGoRootPage successful login for user 'some@where.de' - expire = -1 grace = -1

First Phase of Auth attempt works,then with long password:

Jan 29 23:06:46 sogod [15880]: <0x0x2ab99fc420c8[NGLdapConnection]> Using ldap_init (deprecated) for LDAP host:port 127.0.0.1:389
2013-01-29 23:06:46.753 sogod[15880] -[NGLdapConnection _searchAtBaseDN:qualifier:attributes:scope:]: search with at base filter for attrs `h
1.19.158.172 - - [29/Jan/2013:23:06:46 GMT] "POST /SOGo/connect HTTP/1.1" 200 27/74 0.023 - - 0
Jan 29 23:06:47 sogod [15880]: <0x0x2ab99f1b13d8[NGLdapConnection]> Using ldap_init (deprecated) for LDAP host:port 127.0.0.1:389
Jan 29 23:06:47 sogod [15880]: <0x0x2ab99f13acd8[LDAPSource]> <NSException: 0x2ab99fb50df8> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{login = "uid=some,dc=where,dc=de"; }
Jan 29 23:06:47 sogod [15880]: <0x0x2ab99f1b4e38[SOGoWebAuthenticator]> tried wrong password for user 'zjWxFWqXYqq73sXtuvpkJXtSWLejQwwWH9PnUe4Ahb9SwY61eb/Fn/h1IxwISRHjEm6eEfZUPZexRhL2WnQ5oQ=='!
Then something goes wrong. I dont even know where this strange string comes from. The Part directly above is not showing on user logins with short passwords

31.19.158.172 - - [29/Jan/2013:23:06:47 GMT] "GET /SOGo/some@where.de HTTP/1.1" 200 4358/0 0.019 12340 64% 0

Also if i track LDAP in absulute verbose, this buffer read happens (the password was 'testpassword1234')

0040: 65 80 0b 74 65 73 74 70 61 73 73 77 6f 72 a0 1d e..testpasswor..
0050: 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 0...1.3.6.1.4.1.
0060: 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 31 42.2.27.8.5.1

somehow the rest of the password gets eaten somewhere within sogo

so somewhere within the login phase the long password gets cut

Additional Information

Also my Settings are bindAsCurrentUser = NO, so i don't know why sogo should try to bind as the current user

Centos VServer from hosteurope.de no selinux
Current SOGo repo version 2.0.4a but error exists since i installed, which was version 2.0.3a

Linux version 2.6.18-028stab098.1 (root@rhel5-build-x64) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) 0000001 SMP Sat Feb 11 14:56:17 MSK 2012

Tagsldap

Activities

hrichter

hrichter

2013-02-01 12:03

reporter   ~0005306

Last edited: 2013-02-01 12:12

I could trace the error deeper:

I use bindFields = mail,
because i haven't found a way to make multi-domain-config logins work with
username@domain.com login names if there are equal usernames and passwords within different domains, only the first match gets logged in

i created a test user within a different config with a very long username
longusername_test-domain-long.com
password testtest works
password testtest1 shows the same strange behavior

every password exceeding 8 chars is creating the strange behavior

my conclusion: every combination of user+Password exceeding 41chars will produce this strange behavior with the web interface login screen.

could someone confirm this on another machine?
hrichter

hrichter

2013-02-01 12:17

reporter   ~0005307

Is there a way to change the bug title? my new findings made the old obsolete, its more like
any combination of "user+Password exceeding 41chars"

thanks
Christian Mack

Christian Mack

2013-02-04 10:44

developer   ~0005321

Changed title as requested by bug reporter.
hrichter

hrichter

2013-02-04 18:24

reporter   ~0005326

Jean Raby answered my Mailing List Request. The answer:

Confirmed.

The problem occurs when the username:password exceeds 64 chars.
The following patch should fix it, but it is a friday night patch, so YMMV.

--- a/SoObjects/SOGo/SOGoWebAuthenticator.m
+++ b/SoObjects/SOGo/SOGoWebAuthenticator.m
@@ -388,7 +388,7 @@
// which will be XOR'ed with the user key.
//
sessionKey = [SOGoSession generateKeyForLength: 16];

  • userKey = [SOGoSession generateKeyForLength: 64];

  • userKey = [SOGoSession generateKeyForLength: 768];

    NSString *value = [NSString stringWithFormat: @"%@:%@", username, password];
    securedPassword = [SOGoSession securedValue: value usingKey: userKey];

jraby

jraby

2013-02-04 19:04

viewer   ~0005327

Different fix commited : https://github.com/inverse-inc/sogo/commit/3d90e3a5393ff45b4915a1c915edd4c24b21763c

Will be part of 2.0.4b

Issue History

Date Modified Username Field Change
2013-01-30 21:54 hrichter New Issue
2013-02-01 11:57 hrichter Tag Attached: ldap
2013-02-01 12:03 hrichter Note Added: 0005306
2013-02-01 12:12 hrichter Note Edited: 0005306
2013-02-01 12:17 hrichter Note Added: 0005307
2013-02-04 10:44 Christian Mack Note Added: 0005321
2013-02-04 10:44 Christian Mack Summary Users in LDAP with Passwords longer than 11 chars can't log into Web interface => Users in LDAP with user+Password exceeding 41chars can't log into Web interface
2013-02-04 18:24 hrichter Note Added: 0005326
2013-02-04 19:04 jraby Note Added: 0005327
2013-02-04 19:04 jraby Assigned To => jraby
2013-02-04 19:04 jraby Status new => resolved
2013-02-04 19:04 jraby Resolution open => fixed