> DNS as a Password Manager?<p>Shades of the old NIS+/AUTH_DH/mech_dh scheme. That's a scheme that Sun used in 1987 for NFS security and for authentication. It goes like this:<p><pre><code> - there is a name service called 'publickey'
(i.e., with a getent style API, a 'files'
backend, so /etc/publickey, and a NIS+
backend for domain-based authen.)
- each publickey(5) entry has:
- the name ("netname") of the entity
- a DH group identifier
- a DH public key
and
- the corresponding DH private key
encrypted in the entity's password
</code></pre>
To login you in the system would prompt you for a username and password, lookup your entry in the publickey(5) name service, if found then it would decrypt the private key and confirm that the public key matches.<p>To authenticate to a remote service the system would find that service's publickey(5) entry, compute the shared DH secret, and send a message with the local and remote names, a nonce, and a proof of knowledge of the shared secret.<p>Anyways, you could store publickey(5) in DNS, naturally, if you wanted, though that was never implemented because mech_dh simply died of disuse.<p>It's worth noting that the DNS is mostly public. Yes, you can make zone iteration hard, but not impossible. So if you publish secrets encrypted in low-entropy keys (like typical passwords) then those will be subject to cracking.<p>I do think mech_dh, modernized with ECDH and PQ key agreement, could make a lot of sense to revive. I could totally see a new scheme that's a cross between mech_dh, Kerberos, and JWT.