5 ms·

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 downv

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 implementation details. If a zero day is found in any of their stack, they're a google search away from being found for that.

kristoff_it 9y ago
People say that security trough obscurity is not a good idea.
- PMan74 9y ago
  Keeping the details of your security setup secret or obscure is not security through obscurity. Security trough obscurity is using the secrecy of your security setup as a pillar of that security. It's perfectly sane to keep the details secret even if those details themselves don't form part of your security.
  - laumars 9y ago
    I'd argue that the reasons for wanting to keep implementation details secret would be more political than for security. eg wanting to exaggerate your DR capabilities to would-be customers. Or using tech that works but has a bad image (like Perl). Or perhaps you're just releasing a commercial solution that leverages a lot of open source components and thus could easily be replicated by anyone else. I'm not saying these are good reasons, but they make more sense than the "security" argument because if your infrastructure isn't secure to begin with then it's pretty trivial to find out what is running even without the tech being published / open sourced; and if it is secure then it doesn't really matter if the details were published in the first place.
- cat199 9y ago
  and yet, there are 'information disclosure' vulnerabilities..
  - laumars 9y ago
    There are different degrees of sensitivity though. Infrastructure, eg what Coinbase published, are pretty vague in the real terms. A hacker would still need to approach their target in the same way even with knowing this information. But exploits like Heartbleed could leak information about what users are in /etc/passwd, which is a lot more sensitive since that would significantly reduce the entropy needed for a brute force attack against the host.
alFReD-NSH 9y ago
Coinbase is not the only company doing this. This is actually best practice.
aequitas 9y ago
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/failmap/server https://gitlab.com/failmap/server Diving into a project with a open source mindset really makes me think more about security topics from a different angle and find better solutions. Like reducing the secrets that must be known (and thus can leak), like user/database passwords. Instead of security by obscurity there is nothing to obscure.
- 1ba9115454 9y ago
  The first step of an attack is reconnaissance. How is making that step very easy for an attacker best practice?
  - dijit 9y ago
    If the only thing keeping your attacker out is that they can't do recon then you're kinda boned. Security through obscurity and all that.
  - aequitas 9y ago
    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.
  - jasonlotito 9y ago
    How does releasing this information change that in any way to benefit the attacker?
  - detaro 9y ago
    So in a scenario where you can breach their AWS accounts, it would be a noticeable difficulty for you to discover that they use this pattern to work? I'm not very familiar with AWS, but that seems odd.
weego 9y ago
Good security doesn't require obscurity.
- 1ba9115454 9y ago
  Good security means defence in depth. You secure everything including your backend implementation details.
  - yarrel 9y ago
    Good security means not kidding ourselves that backend implementation details are providing us with any defense. They're not, and if we base our security strategy on the assumption that they are then we have at least one weakness in that strategy.
- cat199 9y ago
  what then is an 'information disclosure vulnerability'?
  - Artemis2 9y ago
    It’s not what you think. It’s more about disclosing business-related data or metadata (e.g. customer names, last time a customer logged in) than technical information (e.g. internal service names, minor debug information).
mxstbr 9y ago
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-code-open-and-reusable#making-code-with-a-security-enforcing-function-open https://www.gov.uk/service-manual/technology/making-source-c... [1]: https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open https://www.gov.uk/government/publications/open-source-guida... [2]: https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the-open/ https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the...
- 1ba9115454 9y ago
  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.
  - cormacrelf 9y ago
    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.
vertex-four 9y ago
If you're a single zero day away from a crippling attack, you're not practising defence in depth, are you?
- peterwwillis 9y ago
  I was literally going to say the exact same thing. +1
peterwwillis 9y ago
Leave your house's front door unlocked and keep a camera outside trained on the door. For the first week, tell nobody that it is unlocked. For the second week, tell everyone you meet that it is unlocked, and provide a map. On the third week your camera records someone going into the house. Did telling people your house was unlocked make your house less secure? Your house was exactly the same in the first week as the second week. Telling people it was insecure did not make it insecure - it was already insecure. You left it unlocked. So it follows that if knowing some piece of information does not reduce the security of your system, then it is not sensitive information, and can be released publicly. On the other hand, if you don't know whether a piece of information reduces your security, you should probably find out. And finally, even if you never release information, that does not mean your house is locked up. But it may lead to a false sense of security.
- vacri 9y ago
  > Telling people it was insecure did not make it insecure - it was already insecure. It's a common tactic for burglars to look for when homeowners are going on holidays. The homeowner being on holiday makes the house less secure, but the information that that particular house is less secure is of benefit to the burglar. Security isn't a binary state.
StreamBright 9y ago
If your entire security can be circumvented with a single zero day it is called coconut security. The whole point of having multiple layers is to prevent a single zero day able to take down your entire infra.

kristoff_it 9y ago

People say that security trough obscurity is not a good idea.

PMan74 9y ago
Keeping the details of your security setup secret or obscure is not security through obscurity. Security trough obscurity is using the secrecy of your security setup as a pillar of that security. It's perfectly sane to keep the details secret even if those details themselves don't form part of your security.
- laumars 9y ago
  I'd argue that the reasons for wanting to keep implementation details secret would be more political than for security. eg wanting to exaggerate your DR capabilities to would-be customers. Or using tech that works but has a bad image (like Perl). Or perhaps you're just releasing a commercial solution that leverages a lot of open source components and thus could easily be replicated by anyone else. I'm not saying these are good reasons, but they make more sense than the "security" argument because if your infrastructure isn't secure to begin with then it's pretty trivial to find out what is running even without the tech being published / open sourced; and if it is secure then it doesn't really matter if the details were published in the first place.
cat199 9y ago
and yet, there are 'information disclosure' vulnerabilities..
- laumars 9y ago
  There are different degrees of sensitivity though. Infrastructure, eg what Coinbase published, are pretty vague in the real terms. A hacker would still need to approach their target in the same way even with knowing this information. But exploits like Heartbleed could leak information about what users are in /etc/passwd, which is a lot more sensitive since that would significantly reduce the entropy needed for a brute force attack against the host.

alFReD-NSH 9y ago

Coinbase is not the only company doing this. This is actually best practice.

aequitas 9y ago

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/failmap/server https://gitlab.com/failmap/server Diving into a project with a open source mindset really makes me think more about security topics from a different angle and find better solutions. Like reducing the secrets that must be known (and thus can leak), like user/database passwords. Instead of security by obscurity there is nothing to obscure.

1ba9115454 9y ago
The first step of an attack is reconnaissance. How is making that step very easy for an attacker best practice?
- dijit 9y ago
  If the only thing keeping your attacker out is that they can't do recon then you're kinda boned. Security through obscurity and all that.
- aequitas 9y ago
  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.
- jasonlotito 9y ago
  How does releasing this information change that in any way to benefit the attacker?
- detaro 9y ago
  So in a scenario where you can breach their AWS accounts, it would be a noticeable difficulty for you to discover that they use this pattern to work? I'm not very familiar with AWS, but that seems odd.

weego 9y ago

Good security doesn't require obscurity.

1ba9115454 9y ago
Good security means defence in depth. You secure everything including your backend implementation details.
- yarrel 9y ago
  Good security means not kidding ourselves that backend implementation details are providing us with any defense. They're not, and if we base our security strategy on the assumption that they are then we have at least one weakness in that strategy.
cat199 9y ago
what then is an 'information disclosure vulnerability'?
- Artemis2 9y ago
  It’s not what you think. It’s more about disclosing business-related data or metadata (e.g. customer names, last time a customer logged in) than technical information (e.g. internal service names, minor debug information).

mxstbr 9y ago

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-code-open-and-reusable#making-code-with-a-security-enforcing-function-open https://www.gov.uk/service-manual/technology/making-source-c... [1]: https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open https://www.gov.uk/government/publications/open-source-guida... [2]: https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the-open/ https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the...

1ba9115454 9y ago
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.
- cormacrelf 9y ago
  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.

vertex-four 9y ago

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

peterwwillis 9y ago
I was literally going to say the exact same thing. +1

peterwwillis 9y ago

Leave your house's front door unlocked and keep a camera outside trained on the door. For the first week, tell nobody that it is unlocked. For the second week, tell everyone you meet that it is unlocked, and provide a map. On the third week your camera records someone going into the house. Did telling people your house was unlocked make your house less secure? Your house was exactly the same in the first week as the second week. Telling people it was insecure did not make it insecure - it was already insecure. You left it unlocked. So it follows that if knowing some piece of information does not reduce the security of your system, then it is not sensitive information, and can be released publicly. On the other hand, if you don't know whether a piece of information reduces your security, you should probably find out. And finally, even if you never release information, that does not mean your house is locked up. But it may lead to a false sense of security.

vacri 9y ago
> Telling people it was insecure did not make it insecure - it was already insecure. It's a common tactic for burglars to look for when homeowners are going on holidays. The homeowner being on holiday makes the house less secure, but the information that that particular house is less secure is of benefit to the burglar. Security isn't a binary state.

StreamBright 9y ago

If your entire security can be circumvented with a single zero day it is called coconut security. The whole point of having multiple layers is to prevent a single zero day able to take down your entire infra.