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

Russ Allbery <[email protected]>
Newsgroups gmane.network.inn
Organization The Eyrie
Message-ID <[email protected]>
"Perry E. Metzger" <[email protected]> writes:
> On 10/4/21 17:25, Russ Allbery wrote:
>> Julien ÉLIE <[email protected]> writes:

>>> 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?

>> In general I'm dubious of the utility of trying to wipe secrets from
>> memory and Cryptography Engineering generally recommends against
>> bothering because there are so many ways to fail, but if it's easy
>> enough to do, I suppose it can't hurt.  (That was the same principle
>> under which I added the explicit_bzero calls to my pam-krb5 module.)

> I'm a big believer in not adding mitigations that don't actually fit a
> particular well defined security model.

Yeah, that's my reluctance too.  In pam-krb5 I was freeing the memory
anyway so adding a one-line call to explicit_bzero() before the free was
essentially zero effort.  But since Julien is talking about changing the
internal structure and doing extra work including disk reads on every
post, I'm not sure it's worth it.

This isn't sufficiently high-security that it's worth designing an
explicit security model, which probably means it's not worth going out of
our way to do things that feel like security mitigations but might not
matter.

-- 
Russ Allbery ([email protected])             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.