On Jun 28, 2016, at 8:36 PM, Ken Hornstein <kenh(_at_)pobox(_dot_)com> wrote:
But if it's a base64-encoded bearer token, that DOES matter. While the
access token used by a bearer token generally has a lifetime, if you can
see it then you can use it at will until it expires. So that suggests
to me that we need to make sure it's not visible via ps(1).
(Note: if my understanding of OAuth is wrong, I welcome a correction;
I am not the expert here).
I haven't drilled into any of the new code, and I confess ignorance of OAUTH in
general. My concern is about protecting the private key, and my glancing read
of the conversation says that, somewhere along the way, an MH command has to
unlock a private key and do a dance with a remote host in order to obtain a
token. This doesn't sound all that different from, e.g., Kerberos, so the same
caveats apply: keep the private key private.
Unlike Kerberos, it seems this new MH code is doing the key management
internally. Therefore I'm quite paranoid about how the private key is being
managed and protected. I haven't seen any sort of security evaluation or
review of the OAUTH code, so all I can do is be a skeptic at the moment.
Without intending to offend anyone, I will suggest the OAUTH bits need a
thorough third-part review before being blessed with a merge into the mainline
code trunk.
--lyndon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers