Live data from Hacker News

Awless: A Mighty CLI for AWS

github.com

51–60 of 120 posts

Re: Awless: A Mighty CLI for AWS

#51
post #23

Earlier quoted context omitted.

Also upload the a hash of the userid and accountid. Hashed with non-random salt so it's not really anonymous as the function says. userid and accountid stored in database here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... retrieved by stats here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... Added to stats payload here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6.…

(I'm one of the core developpers of awless) 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…

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

Re: Awless: A Mighty CLI for AWS

#52
post #23

Earlier quoted context omitted.

Also upload the a hash of the userid and accountid. Hashed with non-random salt so it's not really anonymous as the function says. userid and accountid stored in database here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... retrieved by stats here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6... Added to stats payload here: https://github.com/wallix/awless/blob/e2bf4f2cad37b011c5b3b6.…

(I'm one of the core developpers of awless) 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…

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.

Re: Awless: A Mighty CLI for AWS

#53

Earlier quoted context omitted.

(I'm one of the core developpers of awless) 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…

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.

Re: Awless: A Mighty CLI for AWS

#54

Earlier quoted context omitted.

Wow, and your website isn't even HTTPS for what appears to be a security company. Get it together.

Seems like a non sequitur when discussing an open source project they have released.

The tool phones home. Their website doesn't have HTTPS. It's plausible that the tools phones home over an unencrypted channel (I didn't look, so I could be wrong).

My overall impression is that they don't do security very well.

Re: Awless: A Mighty CLI for AWS

#55

Earlier quoted context omitted.

(I'm one of the core developpers of awless) 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…

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 presen…

What about using SHA512? /s

Re: Awless: A Mighty CLI for AWS

#56

Earlier quoted context omitted.

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 th…

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

Re: Awless: A Mighty CLI for AWS

#57

Just wondering here, but why would you use this vs terraform? Given that I can define most of the stuff I need from AWS in terraform and check the state of the infra via plan command, what would be the use case for CLI? I'm actively trying to break the habit of modifying infra without first writing terraform document for it. This way I can always be sure that I have no surprises when creating a new environment.

Wondering the same... not seeing it...

Re: Awless: A Mighty CLI for AWS

#58

Earlier quoted context omitted.

(I'm one of the core developpers of awless) 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…

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 presen…

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.

Re: Awless: A Mighty CLI for AWS

#59

Can someone explain why this is different/better than the official CLI application?

For me, the output is friendlier, which is great if you're just trying to make a quick query about the running instances or something.

However, the whole thread above pointing out the data collection issues makes me far less likely to be moving away from the official cli + bash magic any time soon

Post reply on HN