Hello,
On Sunday 30 April 2006 08:16, James Harper wrote:
> The bin_to_base64 routine appears to be pretty broken, or at least
> incompatible with the base64 specification.
Yes, it is incompatible with the base64 RFC. I wrote the code before I was
aware that there was a base64 binary specification.
>
> Firstly, this line in bin_to_base64:
>
> reg |= (int8_t)bin[i++];
>
> needs to be changed to:
>
> reg |= (uint8_t)bin[i++] & 255;
>
> or else it gets sign extended and mucks up subsequent digits.
Yes agreed, except that I would say that it "modifies" rather than "mucks up"
the subsequent digits.
>
> Secondly, there is some problem with the way the last digit is handled,
> but I'm not sure what.
The last digit is not shifted as are other digits so the result is right
justified instead of left justified.
>
> If I submitted a patch to fix this would it be accepted?
I have already applied a patch to correct the points you mention above. It was
submitted as a bug report. However, I have some problems about turning it on
(see below).
> Obviously it's
> compatible with itself at the moment, but there may be security
> implications, I think the bug results in a potentially large reduction
> in hash space.
I am really skeptical about the above remark, but it is possible. If it is
true, I would give this problem a much higher probability.
> Also, anyone trying to authenticate to bacula from
> 'outside' the bacula code base (eg me :) is going to run into problems.
Yes, I consider this a security "feature" it means that 14 year old kiddies
using a Perl script will not be able to access Bacula without doing some real
programming. Obviously this won't be an obsticle to anyone serious about
attacking Bacula.
>
> An example, the bacula base64 encoding of the hmac-md5 hash of
> '<[EMAIL PROTECTED]>' and 'd41d8cd98f00b204e9800998ecf8427e'
> (which is in turn the md5 hash of an empty password in hex) is:
>
> T7+uo4/M08/Lw+/N8S/hRB
>
> The 'proper' encoding is:
>
> T76uoozM0svLw+jN8SPhRQ==
> (but you can ignore the equal signs, they're just filler)
Yes, they are different. I have known that for many years now (since I learned
about the binary RFC). That doesn't prove that the first item is any less
secure than the second. The only thing that has happened is that one bit has
propagated changing a value (this could possibly reduce the hash space -- I
am not qualified to answer that), and the end is always different, but
equally valid (i.e. I would be really surprised if this reduces the hash
space).
>
> The bacula encoding after my first bug fix is:
>
> T76uoozM0svLw+jN8SPhRB
> (missing a single bit off of the end I think)
Well, the code to "correct" the encoding is already in version 1.39 in the
current CVS. You can check for yourself what is needed to completely fix it
(more than your fix above, but not much).
For the moment, the code is on a global switch, which is set to reproduce the
old behavior.
The real issue here is that if we change this algorithm, it will make all
authentication incompatible with the prior algorithm. This could be a major
problem for users that have 50 or 60 Bacula clients. For them it is
virtually impossible to upgrade simultaneously.
If this is something that you consider important, then the way to ensure that
it gets implemented in Bacula is to upgrade the current authentication
handshake in a compatible way so that (at least for some time) Bacula can run
both algorithms -- i.e. authenticate a client with either the old or new
algorithm. In fact, I would like to make a major upgrade to this handshake
algorithm so that we can also support SHA1 and other hashing schemes.
If you are anyone else is interested in implementing this, please let me know
and I'll describe what needs to be done.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
