Security in Cancel-Lock password handling (secrets.conf)
Richard Kettlewell
rjk at terraraq.uk
Mon Oct 4 20:37:39 UTC 2021
On 04/10/2021 20:55, Julien ÉLIE wrote:
> Hi all,
>
> Two questions about security and what's the best thing to do with the
> upcoming secrets.conf file containing:
>
> cancels {
> canlockuser: [ password anotherpassword ]
> canlockadmin: [ adminpassword anotheradminpassword ]
> }
>
>
> 1/ Can secrets.conf remain in memory (in a struct) or should it be
> loaded, used, erased with explicit_bzero() and freed for each article
> injection?
nnrpd is network-facing so destroying secrets when not in use seems like
a good strategy. Recall that part of what made Heartbleed so bad was
that it could be used to exfiltrate long-term secret keys from the
victim server.
> 2/ For interoperability reasons, we need to send both sha1 and sha256
> hashes. Yet RFC 8315 has the following MUST:
>
> If multiple <c-lock> elements are added to the Cancel-Lock header
> field by a single agent, each <c-lock> element MUST use a unique
> key "K" to improve security.
>
> The rationale is that "a preimage attack on the different hash
> algorithms may be easier if the attacker knows that the output of those
> hash algorithms was created with the same input" (sha1 and sha256).
>
> Which means that we MUST NOT use "adminpassword" for both sha1 and sha256.
The RFC8315 s4 example for calculating K will produce distinct K for
distinct hashes, _assuming_ that the HMAC is parameterized by the same
hash function as will be used to compute the c-lock-string. (IMO it
would be perverse to violate this assumption.)
i.e.
K1 = HMAC-SHA1(adminpassword, uid+mid)
c-lock-string#1 = Base64(SHA-1(Base64(K1))
K2 = HMAC-SHA256(adminpassword, uid+mid)
c-lock-string#2 = Base64(SHA-256(Base64(K2))
K1 and K2 won't even be the same length.
Also, preimage attacks are wildly unrealistic at present l-)
ttfn/rjk
More information about the inn-workers
mailing list