4 ms·

> In my experience developers don't really get better (as a cohort) at security, most of the improvements in security I've seen are due to better APIs and outso

by bostik 9y ago

> In my experience developers don't really get better (as a cohort) at security, most of the improvements in security I've seen are due to better APIs and outsourcing of low level infrastructure to highly resourced entities. And there is nothing wrong with that, IMO. (Disclosure: I've been immersed in the security field since early 1990's.) Security is complex - stupefiengly complex. No other field in all of CS has to worry about catastrophic failure modes that can be both subtle and completely invisible. Unless you have teams(!) of professionals working on security full time, you have only marginally better chances of survical than a snowball in the tropics. Add the fact that most of the time, security is seen as a lack of something. Mostly usability. People who have work to do will find ways to subvert any and all security measures if doing so makes their life easier. We must accept the fact: it is impossible to sell security. But it IS possible to sell convenience. Make the secure option more convenient than the insecure one, and you can't keep people away. In other words: improve the APIs. Make the underlying infrastructure secure and provide a convenient way of using it properly. Don't try to fight human nature. Make use of it instead.

deleted 9y ago
[deleted]
zxcmx 9y ago
Agree... there's a good argument to be made that the "right" primitive looks more like crypto_box than AES anything and I agree with that too. Sometimes you want things a bit more low level (i.e, that don't dictate s11n) though.
- lann 9y ago
  To be pedantically correct: crypto_box and AES aren't mutually exclusive, and in fact AES is listed in crypto_box's "Alternate primitives".
  - dchest 9y ago
    What an incorrect correction! The commenter's point was: instead of considering a block cipher (AES) as a primitive, developers should consider a higher-level authenticated encryption construction, crypto_box, as a primitive. What you're talking about is a different implementation of crypto_box, which uses AES-GCM with tag included along with ciphertext.
baby 9y ago
That what was done with http/2. Want to use it? Gotta use TLS as well.
- EwanToo 9y ago
  This is the kind of thing that makes security so hard HTTP/2 does not enforce TLS, only the browser implementations do. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption
dsacco 9y ago
> Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usability perspective, or convenient from a risk/financial consequence perspective? I would assume you're using the first definition if you just leave it undefined. But strictly speaking, convenience and security are inherently at odds under the first definition; as stated I don't find that this approach generally works. Security features don't really augment usability so much as they trade off some of it - at best, if you were to make the functionality incredibly seamless and abstract away much or all of the decision making, I suppose you could make secure software as usable as insecure software, but it's not straightforward to design secure software to be as enjoyable to use as insecure software. If we take the example of iMessage: iMessage's security features do not make it intrinsically more or less usable in a general sense; the usability features are those that differentiate it from SMS. Apple happily baked strong cryptography into the protocol as well. An iMessage with the usability features but without the strong cryptosystem would be as useful, and users wouldn't generally be aware of a difference (in fact, it would technically be faster, so in that sense it would more usable). We can't add any further significant security services to iMessage without meaningfully reducing its usability. If iMessage were implemented as a protocol with end-to-end encryption, it would inherently be less usable due to key management and analytics costs on the client-side. This is why I take the position that security and usability are diametric opposites in software design. I've never observed software where this is not the case, unless you contrive the definition of "usability" to mean something like, "the user is hacked less, so they can use the application more" (and I've seen people apply this kind of thinking).
- mikeash 9y ago
  I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors.
  - 9y ago
TheAceOfHearts 9y ago
One of my big problems with security-related topics is that sometimes it's hard to find clear instructions on what you should be doing. We should really have something like a BCP [0] for non-security people. I think the closest thing we have is the Computer Security Resource Center [1], which isn't very approachable and friendly. One recent example I encountered: if I'm generating an ed25519 ssh key, how many KDF rounds should I use? I've seen some guides drop the flag completely, which apparently defaults to 16. But in other places I've seen people saying it should be 100. Is the default value sane or not? [0] https://en.wikipedia.org/wiki/Best_current_practice https://en.wikipedia.org/wiki/Best_current_practice [1] https://beta.csrc.nist.gov https://beta.csrc.nist.gov
- todd8 9y ago
  Your example is spot on. I was looking for guidance on number of rounds just a couple of hours ago and noticed the same thing.
AlphaSite 9y ago
Safety and security I'd argue are the same topic with a different emphasis. They have the same pitfalls and risks and are both incredibly difficult to get right.

by bostik 9y ago

deleted 9y ago

[deleted]

zxcmx 9y ago

Agree... there's a good argument to be made that the "right" primitive looks more like crypto_box than AES anything and I agree with that too. Sometimes you want things a bit more low level (i.e, that don't dictate s11n) though.

lann 9y ago
To be pedantically correct: crypto_box and AES aren't mutually exclusive, and in fact AES is listed in crypto_box's "Alternate primitives".
- dchest 9y ago
  What an incorrect correction! The commenter's point was: instead of considering a block cipher (AES) as a primitive, developers should consider a higher-level authenticated encryption construction, crypto_box, as a primitive. What you're talking about is a different implementation of crypto_box, which uses AES-GCM with tag included along with ciphertext.

baby 9y ago

That what was done with http/2. Want to use it? Gotta use TLS as well.

EwanToo 9y ago
This is the kind of thing that makes security so hard HTTP/2 does not enforce TLS, only the browser implementations do. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption

dsacco 9y ago

> Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usability perspective, or convenient from a risk/financial consequence perspective? I would assume you're using the first definition if you just leave it undefined. But strictly speaking, convenience and security are inherently at odds under the first definition; as stated I don't find that this approach generally works. Security features don't really augment usability so much as they trade off some of it - at best, if you were to make the functionality incredibly seamless and abstract away much or all of the decision making, I suppose you could make secure software as usable as insecure software, but it's not straightforward to design secure software to be as enjoyable to use as insecure software. If we take the example of iMessage: iMessage's security features do not make it intrinsically more or less usable in a general sense; the usability features are those that differentiate it from SMS. Apple happily baked strong cryptography into the protocol as well. An iMessage with the usability features but without the strong cryptosystem would be as useful, and users wouldn't generally be aware of a difference (in fact, it would technically be faster, so in that sense it would more usable). We can't add any further significant security services to iMessage without meaningfully reducing its usability. If iMessage were implemented as a protocol with end-to-end encryption, it would inherently be less usable due to key management and analytics costs on the client-side. This is why I take the position that security and usability are diametric opposites in software design. I've never observed software where this is not the case, unless you contrive the definition of "usability" to mean something like, "the user is hacked less, so they can use the application more" (and I've seen people apply this kind of thinking).

mikeash 9y ago
I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors.
- 9y ago

TheAceOfHearts 9y ago

One of my big problems with security-related topics is that sometimes it's hard to find clear instructions on what you should be doing. We should really have something like a BCP [0] for non-security people. I think the closest thing we have is the Computer Security Resource Center [1], which isn't very approachable and friendly. One recent example I encountered: if I'm generating an ed25519 ssh key, how many KDF rounds should I use? I've seen some guides drop the flag completely, which apparently defaults to 16. But in other places I've seen people saying it should be 100. Is the default value sane or not? [0] https://en.wikipedia.org/wiki/Best_current_practice https://en.wikipedia.org/wiki/Best_current_practice [1] https://beta.csrc.nist.gov https://beta.csrc.nist.gov

todd8 9y ago
Your example is spot on. I was looking for guidance on number of rounds just a couple of hours ago and noticed the same thing.

AlphaSite 9y ago

Safety and security I'd argue are the same topic with a different emphasis. They have the same pitfalls and risks and are both incredibly difficult to get right.