#1667 login problems

[Mikael Sjöberg]

There seems to be a problem in the functions:
OneTimePadEncrypt and OneTimePadDecrypt
in /functions/strings.php

The use of them in encrypting the password corrupts
the password data.

Removing the XOR with $map[$i] solves it. This suggests
a bug in the php base64 functions. One suggestion is to
use crypt() instead.

function OneTimePadEncrypt ($string, $epad) {
$pad = base64_decode($epad);
$encrypted = '';
for ($i = 0; $i < strlen ($string); $i++) {
$encrypted .= chr (ord($string[$i])/* ^ ord($pad
[$i])*/);
}
return base64_encode($encrypted);
}

I used squirrel 1.5.0 and 1.4.3a, php 4.3.9, Win XP,
Apache 2.0.52

/Mikael Sjöberg

[javier wilson]

Logged In: YES
user_id=501964

mikael,

how does this affect your users? none of them can log in
ever? or it just happens sometimes? i am trying to find out
if it is the same problem i have with some users.

[Mikael Sjöberg]

Logged In: YES
user_id=928818

I was evaluating the software so I have never had a working
installation.
You can se the result of this problem in the IMAP server log, if
you configure it to log the passwords in plaintext.
The passwords are randomly truncated by one or two
characters.

Actually, if you add one extra character to the password at
login, you will randomly get access.

PS. There is a typo in the initial description. It should of
course be $pad[$i], not $map[$i] at line 7.

Another thing that strikes me now is why $pad[$i] is fed to
the function ord() when $pad[$i] is binary. This is most
certanly the problem. ord() is strictly not defined for the
whole 8-bit range.

/Mikael S

[javier wilson]

Logged In: YES
user_id=501964

i think this problem has been solved, or at least i can't
seem to find it in CVS 1.5.1, i don't know about using
"ord", but generally most of my users log in with no problems.

[Mikael Sjöberg]

Logged In: YES
user_id=928818

CVS 1.5.1 ??
I have only seen 1.5.0

I used v1.215 (2 Nov 04), of strings.php.

/Mikael S

[Jonathan Angliss]

Logged In: YES
user_id=620333

We cannot use crypt as we have to be able to decode the
script we encrypted. Crypt doesn't allow for that as it is
a one way encryption. We have to decode it because we are
required to pass the plain text version back to the IMAP
server on a regular basis.

I am curious how you are finding that $pad is containing
binary data. Having a brief look over the code, it's
calling a number of functions, but I cannot see any that are
returning any binary data. I could be wrong though, I've
not used half the functions that are involved in this
encryption methodology.

There was an error in the sq_mt_seed function which might
resolve an issue with the encryption. To see the change,
take a look at:

Stable:
http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/functions/strings.php?r1=1.184.2.25&r2=1.184.2.26

Dev:
http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/functions/strings.php?r1=1.212&r2=1.213

I don't see any changes recently that would have any affect
over the encryption/decryption.

[Mikael Sjöberg]

Logged In: YES
user_id=928818

The function base64_decode() will return binary data, thats
its purpose (se http://www.faqs.org/rfcs/rfc2045 section
6.8). So there is no need, and strictly speaking incorrect, to
use the ord() function on the $pad data.

If ord() is the problem, or if the base64_ functions behaves
strangely remains to figure out. The bug history for the
base64_ functions indicates unpredictable behaveour in some
versions of php. There could of cource be something wrong
with the functions producing the $pad data or storing the
encrypted password, but as the encoding and decoding
functions are intended to work, they should be able to handle
that as long as the length of the $pad data exceeds the
length of the string.

As far as I can see, there is no problem with the algorithm
iself, in theory. But it mixes character and binary data in a
way that unnessesarily depends on the implementation of
some function in php (chr and ord).

I am only expressing my educated guess right now, but
hopefully I will have some time in the near future to dig a little
bit deeper into this problem on my non-working configuration.

/Mikael

[Kay]

Logged In: YES
user_id=18608

Hi,

ich have the same problems with OneTimePad, see bug 1102713.

No one of my users can login. I fixed it by disabling the
XOR with the onetimepad, but thats not a real solution.

Kay

[Jonathan Angliss]

Logged In: YES
user_id=620333

Surely if non-binary data goes into the base64_encode
functions, the same non-binary data will come out? If that
is not the case, then how do some clients base64 encode html
emails? Or plain text files? This would suggest a bug in
PHP, unless you are using odd characters for your password?
Is that the case?

Have you had a chance to test SM-1.4.4 yet to see if the
issue still exists?

[Mikael Sjöberg]

Logged In: YES
user_id=928818

Yes, I agree.
As I wrote erlier, the problem must be the unnessesary use of
ord() and char(), which might not be defined or (each others
complement) for the entire 0-255 range.

[Jonathan Angliss]

Logged In: YES
user_id=620333

I just noticed this in the bug list, and it looked like it
may be related to this kind of issue.

Bug 929644 reports that there are unusual behaviour involved
when you're using mbstring_func_overload settings in
php.ini/httpd.conf. This could be the cause of kay's issue,
as it can strip characters off if it is unable to properly
identify the length of a character (details are in the other
bug).

Kay, can you look at that bug, and see if it applies.

misjo, is that the kind of information you were after? the
poster of that bug also mentions binary data.

[Kay]

Logged In: YES
user_id=18608

you're right, 929644 looks like my Problem. I' have an other
randdom Problem with large mailboxes.

I'll check it out and report results.

Kay

[Kay]

Logged In: YES
user_id=18608

OK, it works!

First I changed php.ini:

[mbstring]
mbstring.func_overload = 7
mbstring.internal_encoding = ISO-8859-1

and restore the original OntimePadEncryption() with strlen
and all works well, no login problems!

After that I replace strlen with mb_strlen as suggested
solution in Bug 929644, it works also, regardless of
mbstring.internal_encoding=utf8.

But I have to change back to ISO-8859-1 because of random
hangs on displaying messages in large spam folders.

I strongly suggest to change strlen() to
mb_strlen(,"ISO-8859-1" ) when not working with multibyte
strings.

Kay

[Thijs Kinkhorst]

Logged In: YES
user_id=285765

Two things here:
- Tomas, can you take a look at the mbstring issue since you
seem to be quite knowledgable about that area?
- I wonder indeed why ord and chr are used, why is that
neccessary? If not needed I suggest their removal.

[Tomas Kuliavas]

Logged In: YES
user_id=225877

mbstring.func_overload issue can't be fixed, because php
does not provide options to disable overloading in php
script. In SquirrelMail 1.5.1cvs configtest.php treats
mbstring.func_overload<>0 as fatal error.

http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/src/configtest.php?r1=1.16&r2=1.17

We are trying to solve this issue in 1.5.1cvs by setting
charset to single byte charset.

http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/functions/i18n.php?r1=1.204&r2=1.205

It is possible that use of iso-8859-1 is better than us-ascii.

Password issue can also be fixed by using encryption
functions that operate only with 7bit data. In such case we
might have issues with users using 8bit data in passwords.

There are bunch of comments in both fixes. I can provide
patches for stable by next sunday.

[Tomas Kuliavas]

Logged In: YES
user_id=225877

Issue should be fixed in 1.4.5cvs. functions/i18n.php
v.1.129.2.35

Issue was fixed in 1.5.1cvs about a month ago.
functions/i18n.php v.1.205.