Another badauth problem Another badauth problem

Topic: Another badauth problem

Post Another badauth problem
by kdv666 on jeudi 13 mai 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.

Reply with quote | Report
Post Re: Another badauth problem
by xiaoye on mardi 18 mai 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.


Reply with quote | Report
Post Re: Re: Another badauth problem
by engsysmon on mardi 4 janvier 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.

Reply with quote | Report
jeudi 18 avril 2024 17:14
Loading...