[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antw: Re: Hashed Entries



On Apr 2, 2014, at 11:14 PM, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

>>>> Josh Miller <joshua@itsecureadmin.com> schrieb am 02.04.2014 um 17:58 in
> Nachricht <1EF35D11-9A5F-4161-822A-AAA84F5A2459@itsecureadmin.com>:
>> On Apr 2, 2014, at 3:57 AM, Monica Warnock <monica.warnock@ed.ac.uk> wrote:
>> 
>>> …
>> 
>>> dn: dc=name,dc=name
>>> objectClass: dcObject
>>> objectClass: organization
>>> dc:: ZGxpYi1tb25pZHAg
>>> o:: ZGxpYi1tb25pZHAg
>>> 
>>> dn: ou=Users,dc=name,dc=name
>>> objectClass: organizationalUnit
>>> ou: Users
>>> 
>>> dn: cn=Bob Jones,ou=Users,dc=name,dc=name
>>> cn: Bob Jones
>>> sn: Jones
>>> objectClass: inetOrgPerson
>>> objectClass: eduPerson
>>> eduPersonAffiliation: staff
>>> userPassword:: cGFzc3dvcmQg
>>> uid: bjones
>>> 
>>> 
>>> When I log in as bjones using the correct password the 'username or
> password 
>> is not valid'.
>>> 
>>> What is the relevance of the entries such as the userPassword:: which now 
>> appear with two colons?
>>> 
>>> I have added more test users and on their entry the uid entry also has the
> 
>> double colons with a hashed entry following.
>> ...
>> 
>> If you modify or create an entry with any trailing spaces the results will 
>> be returned base64 encoded (values are stored correctly, but returned this 
>> way).
>> 
>> You can decode with something like the following, which shows that you have
> 
>> a trailing space on your “dc” attribute:
>> 
>>> echo -n "ZGxpYi1tb25pZHAg" | base64 -D
>> dlib-monidp 
>> 
>> I have seen that in many cases if your base64 encoded attributes do not end
> 
>> with a “==" that you have trailing spaces:
> 
> I think whether you see "==" at the end or not is independent of trailing
> spaces, but it depends on how long the input string is.
> (From RFC 4648):
> ---
> 10. Test Vectors
> 
> BASE64("") = ""
> BASE64("f") = "Zg=="
> BASE64("fo") = "Zm8=“

Ah, thank you, Ulrich, you are most correct.  The “=“ character is a pad in base64 encoding.

I had the mis-fortune of executing a test that supported my theory while responding but have since read the RFC you referenced and appreciate the correction.

Thanks,
Josh