encodingdebianbase64basic-authenticationdyndns

decoding two different base64 strings returns two times the same string


base64 encoding / decoding uses deterministic algorithms. Because of that, a given input string will be always encoded to a known output string and vice versa.

Using the browser to access a URL secured with basic authentication, the browser encodes the username:password pair to a base64 string and places that string into the HTTP Authorization request header. Using Firebug it is easy to read that encoded string from the network monitor - let's call it string A.

On a raspberry (running Debian Wheezy) I installed the ddclient to update dns records for my domain using dyndns. The ddclient configuration is provided with the same username:password pair as used to access the URL with a browser. The client even tries to access the same URL (using basic authentication) but the access fails because of a bad authentication. Within the ddclient's debug output I can read the base64 encoded string - let's call it String B.

For any reason String A and String B are different! But they are created from the same username:password pair. If I decode the strings in the Debian shell

echo myBase64EncodedStringGoesHere | base64 --decode

or in the browser console using JavaScript

atob('myBase64EncodedStringGoesHere')

the result is always the same username:password pair, no matter if I decode String A or String B.

My only explanation is that there are maybe some non-visible control characters in the username:password configuration of the ddclient, influencing the base64 encoding result. Thus I checked the ddclient configuration using the vi editor with command

:set list

It looks all good. I am stumped. Does anybody has a glue what's going?

Update 1

because of @C4stor's comment I checked what happens when I take my username:password pair and encode it with the shell command

echo username:password | base64

As result I get String A with padding chars == at the end. Besides from the padding the debian OS created the same string as the web browser (used on Windows) does.

Update 2

As requested by @umläute, here are two demo strings: Stirng A: bXlkb21haW4uY29tOmRueURucz String B: bXlkb21haW4uY29tOmR5bkRucz decoding them in the browser console using

atob('STRING')

gives always the same decoded string.


Solution

  • Within the ddclient's config file there must have been some non-visible control characters, maybe due to a copy & paste...

    Using vi I deleted the content from the file and wrote each line manually by hand. Now the ddclient produces the expected base64 encoded string.

    I still wonder why I wasn't able to see the characters with vi's :set list command, but at least now the problem is solved.