Credentials/keychain/keystore for server applications on FreeBSD?

[Alejandro Imass]

On Mon, Sep 10, 2018 at 2:09 AM, Outback Dingo <outbackdingo at gmail.com>
wrote:

> On Wed, Sep 5, 2018 at 4:55 AM Outback Dingo <outbackdingo at gmail.com>
> wrote:
> >
> > On Wed, Sep 5, 2018 at 4:47 AM Alejandro Imass <aimass at yabarana.com>
> wrote:
> > >
> > > On Tue, Sep 4, 2018 at 9:15 PM, Outback Dingo <outbackdingo at gmail.com>
> wrote:
> > > > On Wed, Sep 5, 2018 at 2:53 AM Alejandro Imass <aimass at 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