Great article and nice tool. Switching role and profile with multiple organizations is indeed cumbersome with AWS.
We are also developing an open source CLI for AWS named awless (cf. https://github.com/wallix/awless). We currently support easy MFA, profile switch and role assuming in CLI with the '-p' flag and are working on extending these features to support multiple organizations. We had multiple issues filed on GitHub which are closely related to this.
Yes, for example at Wallix, we created awless.io a CLI for AWS, that uses RDF (https://github.com/wallix/triplestore) to model cloud data. So far this linked data has help us since it is loosely coupled and has graph-like properties.
Thanks all for the feedback. We understood that the data collection could be done with much care. As a result, until we design a better way to send truly anonymous data, we have disabled the data collection (cf. https://github.com/wallix/awless/commit/f6389e75787390bd7797...). We will let you know when we have something better, keeping everything transparent, as we will always do.
Yeah, this is a huge trust violation. I'm glad people caught on to it quickly. You should not be phoning home with _anything_ from a tool like this without it being 100% opt-in and with huge warnings and alerts. Even if you do it with the most care and best of intentions, a bug could easily compromise security of the people using your tool by uploading too much or the wrong information to your servers. This is not a risk worth taking for you or any potential users of the software.
Because, whether or not we like it, the reality is that data collection is the #1 way for a product to eventually work towards profit? And even if it's a totally free, open-source project with no intention of profiting, too many developers feel like analytics is the only way to gather information to improve?
The easiest way to build awless from source is to use our release script (go run release.go -tag 0.0.13).
Or you can also get the full sources with `go get github.com/wallix/awless`. Then, `go build .` in `$GOPATH/src/github.com/wallix/awless/` should work.
The hash functions are totally unrevertable, so it is impossible to come back to the original identifiers.
We added these anonymous ids, in order to know which commands are the most used per users.
Anyway, if you have better ideas on how to manage this, feel free to make a pull request or create a Github issue. And if you prefer to disable it, you can also do it easily with the source code (you just need to comment a few lines).
You don't need to break SHA256 to de-anonymize these values.
`awless` collects account number hashes. AWS account numbers are 12 decimal digits long, meaning there's a total of 10^12 unique values. Values are anonymized before submission using a single round of SHA256, so in ~2^40 hash operations, anyone with your database of hashes can invert every single account number.
For comparison, the bitcoin blockchain presently has a hash rate of ~2^61 SHA256 hashes per second. (Edit: I incorrectly stated 2^41 based on a hash rate of 3 TH/s, when it's actually 3 million TH/s.)
On my not-so-special spare server, I'm able to pregenerate the hashes with that fixed salt at 344,191 per second. So, it would take only about a month to compute them for every 12 digit AWS account number. And, as mentioned, that's on my not-so-fast spare server, running in one process, one thread.
acct [000003441910] has hash [d2a52833a6e434d2a55be0ce852c2dd9c5260c49a7c28ea4fa3fe2ac6d054d7e] (the last one it finished in 10 seconds)
A little effort with a decent GPU + hashcat though, would take this exercise down to a few minutes.
Good point. Thanks for the advice, we will study quickly how we can improve this.
Our goal is above all to make the usage of AWS easier, and as a result, more secure. We do not want to expose the CLI users to any new threat. We made the source code available to anyone (even the anonymous data collection), to be transparent and get feedback on our work to correct it when needed.
PBKDF2, bcrypt, and scrypt are all used where a database needs to store something and check for equality, but where the values in the database need to not be reversible even if the database is breached. They might be suitable here.
None of those can deal with the case of having too limited of an input range. Even if you use a million rounds, you've only added 2^20 to the workload.
You can create a randomly generated cookie of sorts instead of doing anything with a users' credentials. The supposed accomplished task and end goal would be the same, and yet, people would feel more comfortable.
Your claim that you are using an irreversible hash is not comforting.
Your forced data collection is also not comforting.
> You can create a randomly generated cookie of sorts instead of doing anything with a users' credentials.
That throws off their statistical analysis. Random cookies generates a new cookie for each new install or re-install, inflating the "users" count. If someone installs this on five different servers, the stats under random cookies will show five separate streams of data, and they will draw improper conclusions that a particular operation used on all of those servers if five times more popular than it really is. A configuration flag to disable the data collection is reasonable, but using a well-known hash like Whirlpool to anonymize the data stream is also reasonable.
If someone doesn't like data collection, then they shouldn't use cloud products, and they should just as vociferously declaim cloud services. With cloud services, whether or not the usage data collection is anonymized is at vendor discretion, but here, you control the source. Using a utility for a cloud service, and complaining about usage data collection, is ironic, considering AWS surely collects the same data.
Well of course they do, since all of these commands send off calls to AWS servers. And is you're using AWS products you already trust Amazon, that doesn't mean you trust a random person who put some code on Github.
This whole mess should be opt-in, but it's shocking that anyone thought uploading account IDs hashed with known salts was a good idea. How long did it take you to generate the rainbow table? What you did was more difficult than simply generating a random string as you should have done.
(I'm one of the core developpers of awless).
We are going to add filters and queries very soon. We built awless by relying on RDF to represent the cloud resources. As a result, in addition to simple filters on the properties, we can also represent more complex queries such as "everthing inside a VPC", "the siblings of an instance", etc. Try the `awless show` command to have an insight of what we can do.
When I tried Uber (a few months ago) without Play Services, it was working, but without the location feature. So, if you typed an address, it was working as expected.
