Another badauth problem Another badauth problem

Argomento: Another badauth problem

Post Another badauth problem
di kdv666 su giovedì 13 maggio 2021

I've seen lots of questions here about users getting a "badauth" result when using DDNS. Well, here I am, another one. I'm probably doing something dumb, but I just can't see it.

DDNS isn't working in pfSense,although I think I'm following the instructions on this site.

To simplify matters, I just enter:

https://api.dynu.com/nic/update?username=NNNN&password=PPPP

into my browser ( where, of course, NNNN and PPPP are the username and password respectively that I use to log in to my account here ). And back comes the "badauth" response.

Ok, if I'm doing something really dumb, feel free to slap me with a dead fish, as long as it's not a whale shark.

Rispondi con citazione | Segnalare
Post Re: Another badauth problem
di xiaoye su martedì 18 maggio 2021

Check if your password has some character like ? or & or = that could possibly break the IP update URL. In most cases, the routers/firewalls do URL encoding but that's not always the case.


Rispondi con citazione | Segnalare
Post Re: Re: Another badauth problem
di engsysmon su martedì 4 gennaio 2022

xiaoye wrote:Check if your password has some character like ? or & or = that could possibly break the IP update URL. In most cases, the routers/firewalls do URL encoding but that's not always the case.

Well.... thats why the API documents suggest that the SHA256 representation of the password (or the MD5 representation) should be an option. If the ip update client (user's shell or perl script) is hashing the password properly, and the server is hashing the stored password properly, seems like the comparison of the results on each end should result in a resulting token match.

Rispondi con citazione | Segnalare
giovedì 26 dicembre 2024 07:43
Loading...