Slack To Disable Thousands of Logins Leaked on GitHub (detectify.com) 27
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..."
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..."
I agree this is "bad" (Score:3)
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 [jwsdev.net] 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?
Re: (Score:3)
answering my own, bookmarking to read later:
http://billpatrianakos.me/blog... [billpatrianakos.me]
which was a follow-up to
http://billpatrianakos.me/blog... [billpatrianakos.me]
Re: (Score:2, Interesting)
Isn't that exactly what is being suggested or did you mean everything vs. just the API requests?
Re: (Score:2)
This seems to be what JWT and other token-based auth systems are moving to, as I've kept reading up on things this morning. Thanks.
shouldn't everyone (Score:2)
shouldn't every company that gives out private authentication tokens for developer to use should be monitoring sites like github and revoking any tokens found? when you sign up to get an authentication token it says you have to keep it secret or it will be revoked, so why aren't more people doing this?
Re: (Score:2)
Why? You assume developers who ask for a key are smart enough to protect the things. I mean, they're developers, not users. They should be smart enough to know how to protect their keys. Especially when they u
Re: (Score:2)
Not leaked, published (Score:2)