Re: Security in Cancel-Lock password handling (secrets.conf)

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
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers