> On Jun 28, 2016, at 8:36 PM, Ken Hornstein <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
