Slashdot Mirror


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..."

3 of 27 comments (clear)

  1. I agree this is "bad" by acroyear · · Score: 2

    Any time you keep credentials on a public hub is just a bad thing to do (in a "cross the streams" sense), and I addressed that in a blog entry back when bots were finding thousands of Amazon AWS and S3 OAuth credentials and secret keys made public on github.

    But I do wonder, for libraries that give you an API token to use (Flickr, Trello), how should one use it in a pure html5 single-page client app, one that doesn't use any server proxy middleware. E.g., except for securing the API key, there's no reason for a flickr photo slideshow to ever need to talk to my own server: it should just talk to Flickr directly. 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.

    But if I just leave the API key in the app's scripts, it can, with a little bit of research in the web console, be found by anybody looking for it. Even if I were to encrypt it in some way, that encryption could be cracked easily because everything needed to decode it could also be found because it all is in the javascript somewhere.

    So what if any is the solution for efficient CORS-based HTML5 single page apps for APIs that require a key that you should attempt to secure in some way to prevent others from using the key to create abusive applications of their own?

    --
    "But remember, most lynch mobs aren't this nice." (H.Simpson)
    -- Joe
    1. Re:I agree this is "bad" by acroyear · · Score: 2

      answering my own, bookmarking to read later:

      http://billpatrianakos.me/blog...

      which was a follow-up to

      http://billpatrianakos.me/blog...

      --
      "But remember, most lynch mobs aren't this nice." (H.Simpson)
      -- Joe
    2. Re:I agree this is "bad" by Anonymous Coward · · Score: 2, Interesting

      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.