Slack To Disable Thousands of Logins Leaked on GitHub (detectify.com)

An anonymous reader writes: Thursday one technology site reported that thousands of developers building bots for the team-collaboration tool Slack were exposing their login credentials in public GitHub repositories and tickets. "The irony is that a lot of these bots are mostly fun 'weekend projects', reported Detectify. "We saw examples of fit bots, reminding you to stretch throughout the day, quote bots, quoting both Jurassic Park...and Don Quixote...."

Slack responded that they're now actively searching for publicly-posted login credentials, "and when we find any, we revoke the tokens and notify both the users who created them, as well as the owners of affected teams." Detectify notes the lapse in security had occurred at a wide variety of sites, including "Forbes 500 companies, payment providers, multiple internet service providers and health care providers... University classes at some of the world's best-known schools. Newspapers sharing their bots as part of stories. The list goes on and on..."

Comments

Re:I agree this is "bad"

[Anonymous Coward]

Routing everything through my server as a proxy just for the API key would be horribly inefficient and expensive on my bandwidth, as well as unnecessarily slow

Isn't that exactly what is being suggested or did you mean everything vs. just the API requests?

As for any functionality in your application that requires you to communicate with a third party API you don’t control, the answer is to make a simple CSRF secured AJAX call to your own back-end and then let your server-side application make the API call on behalf of your front-end then return the response back to your client-side app.

My idea (probably not new or unique) would be a signed session key using your API key. So you get the API key and API ID from the third party. Someone requests your HTML5 page. You send them a signed session key (apiid:tempkey:validuntil:signature) in the HTML5 page. The request is made and the third party uses the "public" key to check the signature. You and the third party can limit API access per session, by time, etc. and you can add data with the session key (like read only) because it's been signed by you server side.

It would have to be implemented by the third party but it seems like it might be in their interest.