"It's common for developers inadvertently to include secrets such as API keys and login credentials, unencrypted, in code posted to public repositories. But this isn't quite the same thing." This sounds like it's admitted that screw ups who are "inadvertently" screwing up on a regular basis, is common. Shouldn't be that way. How can someone just inadvertently screw up? No skills? THAT is far more common than people think... As far as this Cloud thing? This is just more evidence that it is not the be all/end all, or best solution.
Last week, Amazon Web Services banned rclone, an open source cloud storage client application, from accessing Amazon Drive, inconveniencing hundreds or possibly thousands of people using the software. The reason turns out to be that the software fails to treat its secrets with suitable discretion. "Rclone has been banned for …
Tuesday 23rd May 2017 07:48 GMT Adam 52
Inadvertently committing API keys is easy. That quick one-off script with embedded credentials because it was only supposed to take a couple of minutes to write and then be discarded, or later version that reads from config but the config lives in the same directory and got swept up in a git add. Or when your tried and trusted .gitignore got left behind.
Or you coded everything right but put a screenshot of the config file in the documentation to show others how to do it, because you're conscientious like that.
It's a problem because even the simplest credentials file rapidly becomes too complex to remember so a template needs to be stored somewhere.
AWS would push server roles, but that comes with a whole load more 'anyone who compromises one server compromises all the cloud stuff it has access to' issues.
As with all these things; there are those who've done it, those who will do it and Reg commentards who criticise from the sidelines.
Tuesday 23rd May 2017 05:49 GMT mdubash
Too good to be true
As a user of rclone for automated server-side off-site backup onto Amazon Cloud Drive, it seemed too good to be true that I could upload terabytes for just 55 quid a year. I should have known better.
My guess is that the bandwidth of thousands of people uploading massive datasets didn't help to make it an economic proposition for Amazon.
Tuesday 23rd May 2017 06:52 GMT Dan 55
Tuesday 23rd May 2017 12:45 GMT Stephen W Harris
Re: Moving keys from source to a server won't fix the problem
The typical way the authentication service works is that the _service_ makes a call to the Amazon API and retrieves a token; that token is passed back to the client. The client uses the token to talk to the API. When the token expires (1 hour later) the client talks, again, to the authentication service and requests a refreshed token.
In this way the client API ID and secret are never exposed to the end user... but it means there are some risks:
1) @ncw doesn't abuse the authentication service and steals tokens :-)
2) Someone else doesn't compromise the service and steals tokens
3) @ncw has to commit to keeping the service running forever and ever (once the authentication service goes down then rclone will no longer work).
The alternative approach of passing the ID/secret to the client at "first run" prevents these risks _but_ effectively means they are no longer secret (as mentioned; add a print statement) and will be leaked, and Amazon will eventually ban them again.
As @ncw says, the google approach of allowing each user to generate and use their own ID/secret is much better.