Using an Update Key

[kasperd]

After reading this announcement, I decided it was a good idea to switch to the new authentication mechanism for tunnels, as it does sound more secure than the old approach.

I did run into one problem though. I'd like to share, what I found out, in case anybody else has been having problems. It turns out, that the new update mechanism does not work, if you choose an Update Key, which is exactly 32 characters long. If instead you choose a longer or a shorter key, it does appear to work.

(Is it a coincidence that this announcement about security improvements came just after the problems on the Stockholm tunnel server appeared to have disappeared?)

[lechner]

A key with 32 characters worked for me, but I had to change the tunnelbroker user ID (the hex string on everyone's main page) to my login user name. Is that the correct way now? Thank you.

[.]

How do I set up this Update Key?

[lechner]

I am not sure what the requirements for the string are, but I took a random, scanned PDF document and ran md5sum over it. That worked for me.

[kcochran]

There are very few things which require the hex user id at this point.  The only one which springs to mind is the non-SSL variant of ipv4_end.php, which won't let you use HTTP Auth parameters by design.

And you can use a 32 character update key, it just has to be all lower case if it doesn't use any non-hex character if you're using ipv4_end.php, due to various case-sensitivity requirements use of the direct use of the intermediate hash causes now and supporting the legacy mechanisms.

Really, using /nic/update is preferred at this time, as it's widely supported due to its API compatibility with existing DDNS update clients, and less parameter creep over the years.