Date: Mon, 10 Sep 2018 06:03:44 -0400 From: Alejandro Imass <aimass@yabarana.com> To: Outback Dingo <outbackdingo@gmail.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Credentials/keychain/keystore for server applications on FreeBSD? Message-ID: <CAHieY7TAOf1L5sECzMVO=JSBg2GMg2mJGAuFG=cmqs0W4fu1pQ@mail.gmail.com> In-Reply-To: <CAKYr3zzVW6H80DQFc96VmzrEdw0oUaBwG1UQS-zHBOrosJuNUw@mail.gmail.com> References: <CAHieY7THk%2BwsbuSmYe8BoWN%2BzuQOqX%2BM-FGLhBqOvptdfYXspA@mail.gmail.com> <CAKYr3zzOPUy9eAhnT3mPKF0Py6Czd2CKk3iKnBR5ZeAfYMw8-Q@mail.gmail.com> <CAHieY7SgfhXsbocX7=5KLTMfqY-pAVttctiEJTh-E0QvCqAgpg@mail.gmail.com> <CAKYr3zxyBF%2B6fS5PzGO_zAt_1KhtyA4Wh9ZWnHmR0Vn_z89bRQ@mail.gmail.com> <CAKYr3zzVW6H80DQFc96VmzrEdw0oUaBwG1UQS-zHBOrosJuNUw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 10, 2018 at 2:09 AM, Outback Dingo <outbackdingo@gmail.com> wrote: > On Wed, Sep 5, 2018 at 4:55 AM Outback Dingo <outbackdingo@gmail.com> > wrote: > > > > On Wed, Sep 5, 2018 at 4:47 AM Alejandro Imass <aimass@yabarana.com> > wrote: > > > > > > On Tue, Sep 4, 2018 at 9:15 PM, Outback Dingo <outbackdingo@gmail.com> > wrote: > > > > On Wed, Sep 5, 2018 at 2:53 AM Alejandro Imass <aimass@yabarana.com> > wrote: > > > >> > > > >> Hi, > > > >> > > > >> Are there any tools that can store application credentials in > encrypted > > > >> form and then provide them to applications in a secure manner at > runtime ? > > > >> > > [...] > > > Vault seems almost exactly what I was looking for! > > > > > > Thank you very much !!! > > > > Your Welcome > > How are you making out with vault for the project you had in mind ? > > > Customer decided to store the clear text token in the PHP code because there is a third party involved and they would not offer support/warranty if we messed with their code etc. So we'll just have to rely on common Unix file protections for now. NVL we will eventually change it to Vault once the initial warranty period is over. BTW and FYR this whole issue arrises because of the careless OAuth 2 implementation of Constant Contact. These guys use Tibco Mashery to deploy their API, but instead of implementing a short lived Access Token with Renewal Token Logic, they issue a 10 YEAR Access Token (ATK) through their development portal and there is no electronic way of revoking it. AFAICT their API has no ACL for the API access itself so if the token is leaked, anyone with the app_key could do any operation on that account, this includes downloading the client lists, creating campaigns and sending mass emails through the hacked account: http://developer.constantcontact.com/docs/developer-guides/overview-of-api-endpoints.html The only way to revoke the ATK is by sending a request to Constant Contact support, and they've acknowledged this publicly since 2014: https://community.constantcontact.com/t5/Authentication-and-Access-ie-401/Regenerate-Access-Token/td-p/225628 Not to mention that Tibco Mashery DOES provide an API to revoking a token but Constant Contact decided not to implement it: https://support.mashery.com/docs/read/mashery_api/20/oauth_supporting_methods/methods/revokeAccessToken Bear in mind that projects involving constant contact are usually done by Web Designers (a.k.a. Web "Programmers") who in turn outsource the development in whole or in part to resources in India, China, Russia or wherever, so these tokens travel through unencrypted email and are also stored in file servers and code repositories. Anyway you get the picture... Our client is lucky we caught this oversight and revoked the development token and issued a new one that was installed on the server directly by us. But imagine how many of these tokens are out there in the wild since Constant Contact is one of the more popular options for spamming, sorry for" email campaigning". All this is shamefully public, and they just done't seem to care or maybe they don't even understand it! Somewhere in Constant Contact's documentation it says that they moved to OAuth 2 to replace the "old" HTTP Basic Authentication scheme for better security. The 1993 rfc2617 that uses MD5 is WAY more secure than most OAuth 2 implementations in the sense that ate least at some point, the clear text user/pass is sent over te wire. I mean, seriously?? How does api_key / ATK differ from user/password?? Also, why do people insist of using OAuth 2 for direct API access instead of using for example rfc7616 ? or hell, even the newer JOSE "standards". But that's not the worse part. PC Magazine recently evaluated Constant Contact and even THEY did not pick up on this horrible security flaw: https://www.pcmag.com/article2/0,2817,2474133,00.asp Honestly man, we are evermore appalled at the stuff we are finding nowadays. People somehow think that "token" is somehow more secure that "password", and we are generally finding that companies are evermore completely ignorant on very obvious security flaws like these. Best, Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHieY7TAOf1L5sECzMVO=JSBg2GMg2mJGAuFG=cmqs0W4fu1pQ>