Dynamic DNS support (DynDNS2) & Automated token flows

[reesericci]

I think it makes sense to support dynamic DNS updating with the DynDNS2 spec, since it's the industry standard with routers & applications.

However, DynDNS uses HTTP basic auth and this would require allowing the issuing of permanent access tokens for dynamic DNS updating (not refresh tokens). This could be a security risk as an attacker could gain control of the access token and utilize it to change the IP address of a record indefinitely unless the token is revoked.

I believe that we can mitigate this risk in these ways:

• The only action that can be taken with a DynDNS token is to push an IP update, that's it.
• Tokens are generated per record, not per zone. This ensures only one record is ever possible to be updated by a DynDNS token. The tradeoff here is that you can't update multiple records with one request.
  • We could maybe explore a system where you could grant access for a specific token to multiple records explicitly selected by a user.
  • Never access to an entire account or zone
• The token never has access to an account (it is impossible to ascertain user info even upon successful request) and it is never possible to determine what records could be changed with just a token.
• Returns 400 on all invalid requests, never return say 401 unauthorized - which allows an attacker to know if they have a valid token, or 403 forbidden - which allows an attacker to know the token is valid, but wrong subdomain. Yes it's security by obscurity, but it's better than nothing.
  • User must send both token & subdomain, and they must both be valid - otherwise generic 400
• Send back no data except 200 OK if successfully updated
• User notification by email & toast upon next login when an IP is updated via a DynDNS token
• Paper trail audit logging (#56) for all updates available to the user to inspect at any time
• Easy revocation of all tokens
• Potentially add expiration dates? This however makes it a worse UX, but I think maybe a 1year expiration could be alright
  • Maybe the user could confirm via email before the expiration to "renew" the token like it was a refresh token
  • External confirmation to renew tokens outside of the app sending another request seems like a really useful feature for entirely automated applications
    • Are you still using Dynamic DNS? This token is about to expire and it was last used on July 4th to update the IP address for reese.obl.ong [YES] [NO]
• Restrict usage of tokens to specific IP addresses and user agents (even if these are spoofable - if the attacker doesn't know it, it could be a useful safeguard)?

I think this could make more sense even for applications like #51 over the device flow which requires the user to re-auth fairly often. Having an "automated token" flow that allows the user - from the domain dashboard for instance - to make tokens with long expiration dates and without a specific client in mind, like personal access tokens, but are extremely narrow in scope. Like say updating individual records I think would be the most common usecase for this, or for ACME/other TXT verification, only allowing creation & deletion of records that have specific regex like "_acme_challenge". A grant flow to exchange for an automated token also would make sense, like initial ACME.sh setup could use the device grant to then save an automated token. However, this would require integrating with Doorkeeper, rather than being a new API (which might be the way to go).

[reesericci]

We should also probably support the duckdns API with the same automated token flow: http://www.duckdns.org/spec.jsp