[GH-ISSUE #77] What is the purpose of having both username and password?

kerem commented

2026-03-13 15:25:07 +03:00

Owner

Originally created by @rmbolger on GitHub (Apr 29, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/77

In the current acme-dns design, each subdomain registration generates a random username and password to authenticate with when updating records. But why have both a username and password when a single password or api token value would do?

In most authentication setups, you have both because the username can be exposed on user facing UI and is considered more or less public info. But in this architecture, the username is kept secret for the duration of its lifetime. So it's really just like you have two passwords that have to be used together. So why not combine them into one value and reduce the complexity a bit?

Originally created by @rmbolger on GitHub (Apr 29, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/77 In the current acme-dns design, each subdomain registration generates a random username and password to authenticate with when updating records. But why have both a username and password when a single password or api token value would do? In most authentication setups, you have both because the username can be exposed on user facing UI and is considered more or less public info. But in this architecture, the username is kept secret for the duration of its lifetime. So it's really just like you have two passwords that have to be used together. So why not combine them into one value and reduce the complexity a bit?

kerem added the

feature request

label

2026-03-13 15:25:07 +03:00

kerem commented

2026-03-13 15:25:18 +03:00

Author

Owner

@joohoi commented on GitHub (Apr 29, 2018):

But why have both a username and password when a single password or api token value would do?

This is the model I began the project with, and wanted to have a bit leeway in implementing features along the way.

But in this architecture, the username is kept secret for the duration of its lifetime. So it's really just like you have two passwords that have to be used together. So why not combine them into one value and reduce the complexity a bit?

This is a good idea, as the design has stabilized and there really is no reason to have both of them. This however is a backward compatibility breaking change, and I'm being careful not to break things for existing users. There are a few more breaking changes in my wishlist however, and I would see this being implemented and released in conjunction with those.

@joohoi commented on GitHub (Apr 29, 2018): > But why have both a username and password when a single password or api token value would do? This is the model I began the project with, and wanted to have a bit leeway in implementing features along the way. > But in this architecture, the username is kept secret for the duration of its lifetime. So it's really just like you have two passwords that have to be used together. So why not combine them into one value and reduce the complexity a bit? This is a good idea, as the design has stabilized and there really is no reason to have both of them. This however is a backward compatibility breaking change, and I'm being careful not to break things for existing users. There are a few more breaking changes in my wishlist however, and I would see this being implemented and released in conjunction with those.

kerem commented

2026-03-13 15:25:23 +03:00

Author

Owner

@rmbolger commented on GitHub (Apr 29, 2018):

The backwards compatibility point is definitely important. Good to know I wasn't missing anything else though.

@rmbolger commented on GitHub (Apr 29, 2018): The backwards compatibility point is definitely important. Good to know I wasn't missing anything else though.

kerem commented

2026-03-13 15:25:29 +03:00

Author

Owner

@Ajedi32 commented on GitHub (May 7, 2018):

A good first step might be to mark the username value as deprecated in the documentation and start ignoring the X-Api-User header, relying only on X-Api-Key. That way existing clients will continue to work, while updated clients can just pretend the username value doesn't exist.

@Ajedi32 commented on GitHub (May 7, 2018): A good first step might be to mark the username value as deprecated in the documentation and start ignoring the `X-Api-User` header, relying only on `X-Api-Key`. That way existing clients will continue to work, while updated clients can just pretend the username value doesn't exist.

kerem commented

2026-03-13 15:25:34 +03:00

Author

Owner

@Ajedi32 commented on GitHub (Aug 3, 2018):

Actually, I just looked a bit deeper at the code and it seems this is a bit trickier than I thought. The API keys are all salted and hashed in the database, so it's not feasible for the API to just accept a key without a username and look up the user that way. (You could do it, but it would involve computing a Bcrypt hash for every single user in the database every time you do a lookup.)

In light of this discovery, I'm no longer certain that getting rid of usernames is a good idea. Even aside from the backwards compatibility concerns, hashing the API keys seems like a great way to protect against possible database leaks (cracking the 40-character random passwords ACME-DNS generates is next to impossible), and switching to a key-only authentication system would necessitate getting rid of that.

@Ajedi32 commented on GitHub (Aug 3, 2018): Actually, I just looked a bit deeper at the code and it seems this is a bit trickier than I thought. The API keys are all salted and hashed in the database, so it's not feasible for the API to just accept a key without a username and look up the user that way. (You _could_ do it, but it would involve computing a Bcrypt hash for every single user in the database every time you do a lookup.) In light of this discovery, I'm no longer certain that getting rid of usernames is a good idea. Even aside from the backwards compatibility concerns, hashing the API keys seems like a great way to protect against possible database leaks (cracking the 40-character random passwords ACME-DNS generates is next to impossible), and switching to a key-only authentication system would necessitate getting rid of that.

kerem commented

2026-03-13 15:25:39 +03:00

Author

Owner

@Ajedi32 commented on GitHub (Aug 3, 2018):

Although... hashing the API keys doesn't necessarily require a salted hash. In fact, since we're using long, randomly-generated keys salting isn't really necessary, nor is key stretching.

New (somewhat more complicated) transition plan:

New API keys are hashed with SHA-256 in the database.
Authenticated requests for existing accounts automatically trigger a migration, changing the API key from being hashed with Bcrypt to one hashed with SHA-256.
Authenticated API requests that don't include a username trigger a lookup by the SHA-256 hash of the API key.
After >3 months of running an updated ACME-DNS server, server administrators may choose to discard old accounts which haven't been upgraded to the new API key version. Those accounts are likely unused, as any Let's Encrypt certificates they might have been used to renew have already expired.

After 3 months of running the new server, this would result in basically the same outcome mentioned in my previous comment, where existing clients will continue to work while updated clients can just pretend the username value doesn't exist.

@Ajedi32 commented on GitHub (Aug 3, 2018): Although... hashing the API keys doesn't necessarily require a salted hash. In fact, since we're using long, randomly-generated keys salting isn't really necessary, nor is key stretching. New (somewhat more complicated) transition plan: * New API keys are hashed with SHA-256 in the database. * Authenticated requests for existing accounts automatically trigger a migration, changing the API key from being hashed with Bcrypt to one hashed with SHA-256. * Authenticated API requests that don't include a username trigger a lookup by the SHA-256 hash of the API key. * After >3 months of running an updated ACME-DNS server, server administrators may choose to discard old accounts which haven't been upgraded to the new API key version. Those accounts are likely unused, as any Let's Encrypt certificates they might have been used to renew have already expired. After 3 months of running the new server, this would result in basically the same outcome mentioned in my previous comment, where existing clients will continue to work while updated clients can just pretend the username value doesn't exist.

kerem commented

2026-03-13 15:25:44 +03:00

Author

Owner

@rmbolger commented on GitHub (Aug 3, 2018):

Sounds good to me.

@rmbolger commented on GitHub (Aug 3, 2018): Sounds good to me.

kerem commented

2026-03-13 15:25:49 +03:00

Author

Owner

@Yannik commented on GitHub (Jan 9, 2019):

@Ajedi32 Are you going to open a PR for your proposal? :-)

@Yannik commented on GitHub (Jan 9, 2019): @Ajedi32 Are you going to open a PR for your proposal? :-)

kerem commented

2026-03-13 15:25:54 +03:00

Author

Owner

@Ajedi32 commented on GitHub (Jan 9, 2019):

@Yannik Not for the foreseeable future, unfortunately. If you want, you're welcome to take it on yourself.

@Ajedi32 commented on GitHub (Jan 9, 2019): @Yannik Not for the foreseeable future, unfortunately. If you want, you're welcome to take it on yourself.

kerem commented

2026-03-13 15:25:59 +03:00

Author

Owner

@tcely commented on GitHub (Mar 3, 2019):

The alternative I chose was to do the lookup using the subdomain provided for /update in the POST data. We could also choose to keep username and password, but make subdomainoptional instead. That just seemed less flexible to me because having multiple subdomain values in the account isn't possible with that approach.

This way the required data is password, subdomain, and txt which can all be provided in the POST data. No special headers are required.

@tcely commented on GitHub (Mar 3, 2019): The alternative I chose was to do the lookup using the `subdomain` provided for `/update` in the `POST` data. We could also choose to keep `username` and `password`, but make `subdomain`optional instead. That just seemed less flexible to me because having multiple subdomain values in the account isn't possible with that approach. This way the required data is `password`, `subdomain`, and `txt` which can all be provided in the `POST` data. No special headers are required.

kerem referenced this issue

2026-03-13 16:13:52 +03:00

[PR #29] [MERGED] Support for multiple TXT records per subdomain #253

Rows
Columns

[GH-ISSUE #77] What is the purpose of having both username and password? #29