Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS bastions and assume-role

engineering.coinbase.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: AWS bastions and assume-role

#11

Post by mxstbr »

1ba9115454 wrote: post #2

As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…

This is, maybe counterintuitively, not true. If anything, Coinbase is more secure than before by publishing this.

For a great and well-reasoned argument see the Gov.UK guidelines, which state that all of their new code has to be open source. (yes, that's the UK government, not some startup) They even specifically mention security-enforcing code![0]

> Code that contributes to your service’s security does not need to be kept closed. Many security-enforcing functions, such as cryptographic algorithms, are provably better when openly examined and understood while the keys are kept private.

They also have another guide and a blog post specifically about security considerations with open source code.[1][2]

> Doesn’t it give attackers an advantage?

> Although there’s a common concern that coding in the open could give an advantage to an attacker, we believe that only a negligible advantage exists. [...] In fact there is no evidence to suggest that being open source makes software more susceptible to exploitation.

I would highly recommend reading through those if you really think Coinbase is now under a higher risk of attack due to this article. They aren't.

[0]: https://www.gov.uk/service-manual/technology/making-source-c... [1]: https://www.gov.uk/government/publications/open-source-guida... [2]: https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the...

Re: AWS bastions and assume-role

#12

Post by fxaguessy »

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.

Re: AWS bastions and assume-role

#13

Post by 1ba9115454 »

weego wrote: post #8
1ba9115454 wrote: post #2

As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…

Good security doesn't require obscurity.

Good security means defence in depth. You secure everything including your backend implementation details.

Re: AWS bastions and assume-role

#14

Post by aequitas »

1ba9115454 wrote: post #9
aequitas wrote: post #6

Earlier quoted context omitted.

This is actually a best practice and I believe Amazon also advises this. So it's not really something secret. For me as a customer it is good to know they follow these practices and communicate their understanding of it outwards. For private projects I have been experimenten with how far I can go in open sourcing everything (including server configuration) and where you hit limits. Example project: https://gitlab.com…

The first step of an attack is reconnaissance. How is making that step very easy for an attacker best practice?

Part of that reconnaissance is running vulnerability testing suites. I think that they will give a quicker answer to most of the questions than having to read through the configuration code and piecing it together. Often I myself even prefer running nmap instead of looking at the code to check some configuration.

Re: AWS bastions and assume-role

#15

Post by 1ba9115454 »

mxstbr wrote: post #11
1ba9115454 wrote: post #2

As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…

This is, maybe counterintuitively, not true. If anything, Coinbase is more secure than before by publishing this. For a great and well-reasoned argument see the Gov.UK guidelines, which state that all of their new code has to be open source. (yes, that's the UK government, not some startup) They even specifically mention security-enforcing code![0] > Code that contributes to your service’s security does not need to b…

There's no proof there that they are now at less risk.

I've looked at the code and I can see already some potential supply channel attacks as they are not hash protecting their incoming libraries.

Re: AWS bastions and assume-role

#17

Post by vertex-four »

1ba9115454 wrote: post #2

As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…

If you're a single zero day away from a crippling attack, you're not practising defence in depth, are you?

Re: AWS bastions and assume-role

#18

Post by cormacrelf »

1ba9115454 wrote: post #15
mxstbr wrote: post #11

Earlier quoted context omitted.

This is, maybe counterintuitively, not true. If anything, Coinbase is more secure than before by publishing this. For a great and well-reasoned argument see the Gov.UK guidelines, which state that all of their new code has to be open source. (yes, that's the UK government, not some startup) They even specifically mention security-enforcing code![0] > Code that contributes to your service’s security does not need to b…

There's no proof there that they are now at less risk. I've looked at the code and I can see already some potential supply channel attacks as they are not hash protecting their incoming libraries.

It seems to be extrapolated from open crypto code, which is a unique example. Nobody goes around volunteering security reviews of CRUD apps like they do for interesting crypto.

If you're open sourcing stuff that other people use, it makes sense, because people fix security issues from using software, fixing bugs and witnessing failures, and needing the fixes for themselves. Not from going 'wow, that's 500 repositories, most of which I don't care about at all'. You're not going to go fix the issues you just saw, are you?

In this case, Coinbase open-sourced some useful code (with an install-this-one-liner), and details of a systematic security method that other people can also use themselves, critique and improve on. The difficulty of breaking their setup hasn't changed, simply by knowing that the keys/MFA combo you really want is a different one. You'd still need to steal it. Perfect example of helping security by transparency.

Re: AWS bastions and assume-role

#20

Post by bpicolo »

dantiberian wrote: post #7

In Google Cloud, something like this is mostly unnecessary. The project model scopes resources to a particular project within an organisation, rather than all resources being global to the account. This gives a really good first cut at isolating different environments and projects.

This goes beyond just prod/staging. It allows you to easily manage fine-grained roles down to e.g. particular microservices and also control how users can access those resources as minimally as is necessary.

So you can recreate the project-model here, and also refine it beyond that.

Post reply on HN