4 ms·

FTA: "U2F Zero ... the only token on Amazon that has open source firmware (and hardware designs) ... you value the coolness factor of it being open-source"

FTA: "U2F Zero ... the only token on Amazon that has open source firmware (and hardware designs) ... you value the coolness factor of it being open-source" Coolness factor? The openness of software and hardware is very important for a security device as this. We should expect something so critical and simple to be easily auditable.

vog 9y ago
It is really a pity that FOSS is not yet a strict requirement for every security-relevant component. This is especially strange given that "Security by Obscurity doesn't work" and "Nobody can analyze code which they can't easily build and modify" are well established concepts by now.
- dsacco 9y ago
  > Security by Obscurity doesn't work. Yes it does! This meme is both widespread and incorrect. Security by obscurity is a great layer for defense in depth. The only time it's not sane is when it's used as the only method. But that's also like saying whitelisted input or parameterized queries don't work - they don't work on their own, but all things being equal you can have very secure systems that function in an opaque way while still getting strong assurances through formal audits. > Nobody can analyze code they can't build and modify. Essentially no one analyzes open source code regardless, unless they have a financial incentive. Even if you are one of the vanishingly small number of people who inspect the code for every FOSS tool you use, you are, with probability approaching 1, incapable of identifying all potential backdoors or critical security failures. You need to balance the Platonic ideal of open software for audits with the fiscal reality that secure software is highly expensive and typically emerges as the product of well funded teams with significant expertise. This describes very few open source projects.
dsacco 9y ago
It's a myth that open source tools are more secure than closed source tools. Use whatever tool is put out by the team with the most expertise and the least reason to do something untrustworthy (or alternatively: the most to lose). A backdoor can persist in open source tools just as easily as it can persist in proprietary ones, and teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools.
- CaptSpify 9y ago
  > It's a myth that open source tools are more secure than closed source tools. It's a myth that they are always more secure, but my experience has been that they are generally more secure. I'd love it if we had some statistics behind this. I would argue that foss tools have an inherent interest in being more secure, while closed-source tools have an inherent interest in being less secure.
- mikegerwitz 9y ago
  The "open source" development model is based on the claim that it produces superior software. Of course that claim will be made. But I agree that it is a fallacious claim. _However_, there are strong benefits of anyone being able to audit the code rather than just privileged entities (see below). Security is also about trust. I can't trust non-free software as a matter of principle---the developers, by keeping something proprietary, are hiding something from their users. The intent is irrelevant---"trade secrets" or not, the fact is there. Back to code audits: a common rebuttal is that you can audit certain proprietary software through the signing of nondisclosure agreements. The trust then shifts to the auditor, performing an extremely complicated job (depending on the software). Nobody can verify their work, or even the integrity of the work. Certain types of changes can be "audited" by chance in Free systems: malicious commits/patches to free software is an extremely risky operation because of the chance that you may be found out. You can set yourself up for plausible deniability, but that can hurt your reputation, and the reputation of the project. Since trust is an important aspect of security, non-free software is by default less secure _to me_. It isn't even an option.
- eeZah7Ux 9y ago
  > A backdoor can persist in open source tools just as easily as it can persist in proprietary ones Just as easily? Citation needed. Especially when we are talking about a simple security device that can ship a tiny, well written, well documented codebase. > teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools This is besides the point. The same code, developed by the same team, can be released, or simply made publicly auditable.

vog 9y ago

It is really a pity that FOSS is not yet a strict requirement for every security-relevant component. This is especially strange given that "Security by Obscurity doesn't work" and "Nobody can analyze code which they can't easily build and modify" are well established concepts by now.

dsacco 9y ago
> Security by Obscurity doesn't work. Yes it does! This meme is both widespread and incorrect. Security by obscurity is a great layer for defense in depth. The only time it's not sane is when it's used as the only method. But that's also like saying whitelisted input or parameterized queries don't work - they don't work on their own, but all things being equal you can have very secure systems that function in an opaque way while still getting strong assurances through formal audits. > Nobody can analyze code they can't build and modify. Essentially no one analyzes open source code regardless, unless they have a financial incentive. Even if you are one of the vanishingly small number of people who inspect the code for every FOSS tool you use, you are, with probability approaching 1, incapable of identifying all potential backdoors or critical security failures. You need to balance the Platonic ideal of open software for audits with the fiscal reality that secure software is highly expensive and typically emerges as the product of well funded teams with significant expertise. This describes very few open source projects.

dsacco 9y ago

It's a myth that open source tools are more secure than closed source tools. Use whatever tool is put out by the team with the most expertise and the least reason to do something untrustworthy (or alternatively: the most to lose). A backdoor can persist in open source tools just as easily as it can persist in proprietary ones, and teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools.

CaptSpify 9y ago
> It's a myth that open source tools are more secure than closed source tools. It's a myth that they are always more secure, but my experience has been that they are generally more secure. I'd love it if we had some statistics behind this. I would argue that foss tools have an inherent interest in being more secure, while closed-source tools have an inherent interest in being less secure.
mikegerwitz 9y ago
The "open source" development model is based on the claim that it produces superior software. Of course that claim will be made. But I agree that it is a fallacious claim. _However_, there are strong benefits of anyone being able to audit the code rather than just privileged entities (see below). Security is also about trust. I can't trust non-free software as a matter of principle---the developers, by keeping something proprietary, are hiding something from their users. The intent is irrelevant---"trade secrets" or not, the fact is there. Back to code audits: a common rebuttal is that you can audit certain proprietary software through the signing of nondisclosure agreements. The trust then shifts to the auditor, performing an extremely complicated job (depending on the software). Nobody can verify their work, or even the integrity of the work. Certain types of changes can be "audited" by chance in Free systems: malicious commits/patches to free software is an extremely risky operation because of the chance that you may be found out. You can set yourself up for plausible deniability, but that can hurt your reputation, and the reputation of the project. Since trust is an important aspect of security, non-free software is by default less secure _to me_. It isn't even an option.
eeZah7Ux 9y ago
> A backdoor can persist in open source tools just as easily as it can persist in proprietary ones Just as easily? Citation needed. Especially when we are talking about a simple security device that can ship a tiny, well written, well documented codebase. > teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools This is besides the point. The same code, developed by the same team, can be released, or simply made publicly auditable.

FTA: "U2F Zero ... the only token on Ama­zon that has open source firmware (and hard­ware de­signs) ... you value the cool­ness fac­tor of it being open-source"

FTA: "U2F Zero ... the only token on Ama­zon that has open source firmware (and hard­ware de­signs) ... you value the cool­ness fac­tor of it being open-source"

FTA: "U2F Zero ... the only token on Amazon that has open source firmware (and hardware designs) ... you value the coolness factor of it being open-source"

FTA: "U2F Zero ... the only token on Amazon that has open source firmware (and hardware designs) ... you value the coolness factor of it being open-source"