#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
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


1 2 > >> (Page 1 of 2)
  • javier wilson
    javier wilson

    Logged In: YES


    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.

  • Logged In: YES

    I was evaluating the software so I have never had a working
    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

    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
    javier wilson

    Logged In: YES

    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.

  • Logged In: YES

    CVS 1.5.1 ??
    I have only seen 1.5.0

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

    /Mikael S

  • Logged In: YES

    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:



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

    • assigned_to: nobody --> jangliss
  • Logged In: YES

    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.


  • Kay

    Logged In: YES


    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.


  • Logged In: YES

    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?

  • Logged In: YES

    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.

1 2 > >> (Page 1 of 2)