How to secure anything
github.com
How to secure anything
1–10 of 25 posts
Re: How to secure anything
#2Pretty good anthology of info here, but, no commits in over a year ?
Re: How to secure anything
#3This list comes up often without discussion:
https://news.ycombinator.com/from?site=github.com/veeral-patel
Re: How to secure anything
#4If you are interested in this topic, can't recommend this book enough: https://www.cl.cam.ac.uk/~rja14/book.html
The 3rd edition is expansive (1000 pages, plenty of references) but readable. Free PDFs of previous editions are available at that link.
Re: How to secure anything
#5This is missing an extremely important upfront concept: you need to know what you're protecting and how valuable it is.
It does no good whatsoever to require every user of a grocery-list app to have a Yubikey to verify their identity. It might not even make sense to have users login at all.
The balance between usability and security must be consonant with the costs of implementation.
Re: How to secure anything
#6This is missing an extremely important upfront concept: you need to know what you're protecting and how valuable it is. It does no good whatsoever to require every user of a grocery-list app to have a Yubikey to verify their identity. It might not even make sense to have users login at all. The balance between usability and security must be consonant with the costs of implementation.
Unfortunately, if you force users to pick between usability and security, they'll ignore security every time.
Or as I often say "no one ever says, 'wow, that was a great login experience', they just want to get to the features behind that experience (hopefully securely behind it)".
Re: How to secure anything
#7Pretty good anthology of info here, but, no commits in over a year ?
Hmm, probably outdated then.
:)
Re: How to secure anything
#8This is missing an extremely important upfront concept: you need to know what you're protecting and how valuable it is. It does no good whatsoever to require every user of a grocery-list app to have a Yubikey to verify their identity. It might not even make sense to have users login at all. The balance between usability and security must be consonant with the costs of implementation.
Unfortunately, if you force users to pick between usability and security, they'll ignore security every time. Or as I often say "no one ever says, 'wow, that was a great login experience', they just want to get to the features behind that experience (hopefully securely behind it)".
And maybe that's OK in many cases?
Sure, banks must enforce good security, but a lot of other things should not care.
Like online stores for example. As long as I am paying paypal, the only info my account has is email, address and recent orders. One can google my address in about 20 minites anyway, and this means I really don't care about account security. If there was an option to login without password using email alone, I'd probably pick it.
Re: How to secure anything
#9This is missing an extremely important upfront concept: you need to know what you're protecting and how valuable it is. It does no good whatsoever to require every user of a grocery-list app to have a Yubikey to verify their identity. It might not even make sense to have users login at all. The balance between usability and security must be consonant with the costs of implementation.
Unfortunately, if you force users to pick between usability and security, they'll ignore security every time. Or as I often say "no one ever says, 'wow, that was a great login experience', they just want to get to the features behind that experience (hopefully securely behind it)".
See the thread from earlier today about login.gov
Re: How to secure anything
#10This is missing an extremely important upfront concept: you need to know what you're protecting and how valuable it is. It does no good whatsoever to require every user of a grocery-list app to have a Yubikey to verify their identity. It might not even make sense to have users login at all. The balance between usability and security must be consonant with the costs of implementation.
I believe that was covered, but it was under the context of security policy vs a more direct description. The key point I'd pull out is: "The goal isn't to eliminate risk entirely, but bring it down to an acceptable level."
There could be (and probably are) entire books written about how to define what "an acceptable level" means... but that is the same point you are getting at - security is not a guaranteed lockdown of your assets, it is self-defined sufficient deterrence to attack. Sometimes that means light security, sometime that means heavy... but it is up to you to make those decisions.