281 karma · joined February 5, 2011
https://en.wikipedia.org/wiki/Scientific_theory#Essential_cr...
Would be nice but no, not really. The standards you mentioned are mostly compliance requirements. To be honest, a good chunk of the industry considers them as kind of a joke from a security perspective.
> It's comprehensive and not that hard to learn
Have you even read these standards? I mean, they might be "not hard to learn" but they are far from comprehensive (or specific, depending on which one you are looking at)
> Twitter are not remotely close to operating like that given their recent hacks
Ask literally any security professional you trust, companies compliant with PCI DSS and ISO27k1 get security incidents and breaches all the time just like everyone else and possibly more (given that if they need compliance with these standards they are probably big enough to have very wide/heterogeneous infrastructure/applications portfolio/administration practices/etc). If they claim they don't, that's most likely because their telemetry sucks (so, it still happens they just don't know about it)
Related, discussed on HN a while ago: https://blog.dshr.org/2020/05/the-death-of-corporate-researc... Previous discussions https://news.ycombinator.com/item?id=24200764 and https://news.ycombinator.com/item?id=23246672
However, and this is mostly for the sake of others reading this, be aware that the security industry has its own versions of the problems mentioned affecting the academic environment, and these versions are in most cases way worst than in academia. With the exclusion of some enlighten cases (which most often coincide with a good financial situation that allows for teams that do cool stuff without too-pressing metrics on the immediate business), in private companies literally everything is driven by money and to that one must add up that the incentives that the people part of the companies have (to this: in private companies the turnover is way higher than in academia). Some examples:
- Papers that don't deserve to be written? wait for that endless stream of tasks that does not deserve to be done that way (but need to be done that way the same, because <reason-you-cannot-argue-against>).
- Optimizing for the wrong things? wait for words like "cost-effective" to pop up.
- Move away from very cool stuff? yeah, that does not happen because the cool stuff are not even on the table, unless they can bring in money fast.
- Non peer-review things dismissed? wait for not-approved-by-manager-X or not-in-the-agenda-of-key-person-Y or subject-to-approval-of-Z-who-cannot-possibly-even-understand-the-value-of-that.
- No time for tech stuff? sorry, that doesn't change much unless your job is highly operational (which you won't enjoy much because it will have to be "cost-effective", thus most likely repetitive and metrics-based).
I'm not saying that every private company is a circle of hell in the security industry, but unfortunately most have far harder-to-deal-with problems than those listed for people looking for things like the author. Afaik, the common big difference is you get paid more and you see real-world cases as they happen.
(edit: formatting)
And yes, I blame the victims for their/our short-sightedness, it's not like anyone forced people to buy and re-buy broken products for decades.
And then stuff dies after a short time. And/or is just left forgotten because it's more broken/an annoyance than it is useful. Or, and this is key, you are stuck with it because for a mix of reasons there is no viable alternative.
One would expect that on the long run the ultimate victims of this (the users of technology) would realise that rather then the ten thousand loads of tech crap they buy they would be much better off with a bunch of stuff that actually works without annoyances for a better quality of life but people just don't. Because again, pricing and marketing.
It used to be _create value and make a profit from it_, now it's the other way around: _aim for profit and consider creating value as a cost of doing so_ (and therefore should be minimised, who gives a frack if the user is annoyed or the thing is broken as long as there is profit).
People has been even trained for decades by major products in the industry to accept that tech doesn't work/is broken/sucks. The good stuff we have exist because at some point for some small time quality became competitive advantage, then on top of that other cycles of craploads piled on.
We did this.
I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it.
> People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point.
So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure.
> Slowing down your adversaries and weeding out the low-effort attacks is still valuable.
Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers.
> That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said.
The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this. I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.
From Wikipedia: "reliance [...] on design or implementation secrecy as _the main method_ of providing security [...]"
So, to use the model mentioned in the article, a single slice of cheese. It's not "an additional layer of defense", it's the main one (so you have other... weaker layers? ¯\_(ツ)_/¯)
Second, "reliance on secrecy of design and implementation" is different from "reliance on secrecy of _whatever-else_", because design and implementation are most often either easily discoverable (sure, occasional skids might not scan port 64323 but what about someone who can observe your traffic?) or pretty much guaranteed to be discovered by adveraries with (not even as much as one might think) time and motivation.
Third, some of the examples mentioned (e.g., the decoy cars) are not even security by obscurity, that's called deception.
So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense.
Security by obscurity is not underrated, by definition it's just bad.
[0] https://www.icann.org/resources/pages/faqs-2013-11-26-en
I understand the will to take action, but doxing a phishing site can cause collaterals you did not foresee and you want to avoid, legally and otherwise. And it doesn't solve anything, as previously explained, it just temporarily turns them down, which leads to a comparison between the time invested by the adversary (who will block your source as first thing) and yours (and you don't want to go there). Definitely is not something to suggest to inexperienced people as "a good way to fight phishing" (which they'll take literally, because it looks cool). There might be exceptions to this (as in, calculated risks) but they go far beyond what makes sense for someone alone to do.
As per the box legitimate owner, while I agree that there is all kind of crazy out there and you can avoid this if it makes you uncomfortable (abuse-at-provider will most likely contact them shortly without involving you), I don't see the lash out or strike at you scenarios likely, in my experience usually you get a thank you.
To be clear, I'm not suggesting email "Bro, you are compromised, bye", I mean, you can just inform them that you received the link and were taken to a phishing site that looks like hosted on his machine, attach screens, advice them on next steps if you want to go the extra mile in niceness. You're doing them a favour without breaking any law, why would they get mad at you?
Phishing sites can be / are often served by compromised hosts, so you might as well end up doxing a box who is not run by the bad guy, causing all sorts of mayem for the legitimate owners / admins (in addition to they be compromised).
Plus, you didn't solve anything, from the pattern you used it's pretty easy to cleanup the data for the adversary, get rid of your garbage and put the thing back on the next day, so you've only temporarily disrupted their operation.
A more appropriate response is to report the abuse who manages the infrastructure (most likely a legitimate provider) and the domain registar; both usually have appropriate channels and response procedures just for that. If you feel kind and keen to do some free work, you can find out if the infrastructure has also a legitimate purpose and contact the legitimate administrator. Also, there are a lot of abuse lists that accept contributions, as in submitions for malicious sites, where you can report this (so it gets fetched by a variety of stuff and blocked by others while it's operational before it gets eradicated).
I understand this does not give you any credit or allow you to write a blog post about looping requests in bash but still.
TBH, although this might be an unpopular opinion among vim users, I don't think vim is worth for coding beyond simple scripting, a decent setup requires way too much work which defeats one of its key points. But for everything else in editing files, nothing compares.
To clarify, being held captive "by a sane adversary" until you supposedly decrypt allegedly encrypted data is different from falling into the hands of someone willing and enabled to torture you. Unless you consider torure a "sane" practice. If you cannot understand the difference maybe you should follow your own recommendation and learn a little more.
It does not. I think your mistake is modelling an adversary willing and enabled to torture like an entity that behaves like you would do, which I assume is according to logic + knowledge + willing/able to communicate + respect for human life.
How about the adversary just not buying your proof and torture you anyway (to death) just in case you are trying to deceive? How about the adversary not even giving you the opportunity to explain or show your proof? (imagine getting yelled "open it" because they don't speak much english other than that and get beaten for whatever you do that doesn't look like "opening it")
I'm writing this just in case someone reading will actually at some point need to prepare for such threat. "Proof of inability to decrypt" (as also "Denial of encryption") does not give you a way out of the "XKCD 538 scenario". If you can't avoid the scenario entirely, there are better bets (e.g., disguise still-encrypted data as plausible, non-sensitive other data).
I find it naive suggesting that "Proof of inability to decrypt" can lead to a positive outcome in such scenario.
There is a system in place that tracks and records some things, like days off prescribed by base doctors, prescriptions for which national care pays and few other stuff, but most of everything else, including charts from when you are admitted in most hospitals and of course whatever you do outside of the public care (which kind of sucks and has insane waiting times, which means you most often do) is not included in that.
So.. nope.
Somewhere in a post from a couple of years ago I read "a vision of a different world: one with the flexibility of Smalltalk, the power of Lisp, while still allowing for compilation to efficient code", but as someone said in a comment to the link of that post in HN these these are already covered (and if not, they have a lot of people working on them) by other more popular (and more friendly imho, from the few examples I had a look to) languages..
So again, why Dylan?
import inspect
def autoinit(decorated_init):
def _wrap(*args, **kwargs):
obj, nargs= args[0], args[1:]
names = decorated_init.func_code.co_varnames[1:len(nargs)+1]
nargs = {k: nargs[names.index(k)] for k in names}
kwa_keys = decorated_init.func_code.co_varnames[len(nargs)+1:]
kwa_defaults = inspect.getargspec(decorated_init).defaults
for k in kwa_keys:
nargs[k] = kwargs[k] if (k in kwargs) else kwa_defaults[kwa_keys.index(k)]
for k, v in nargs.iteritems():
setattr(obj, k, v)
return decorated_init(*args, **kwargs)
return _wrap
if __name__ == '__main__':
class Foo():
@autoinit
def __init__(self, a, b, x=0, y=0):
self.p = 'Hello, I am set inside the __init__'
self.s = self.a + self.b + self.x + self.y
f = Foo(1, 2, x=120, y=5)
for param in 'abxyps':
print param, '=>', getattr(f, param)
f = Foo(31, 33, x=64)
for param in 'abxyps':
print param, '=>', getattr(f, param)
f = Foo(7, 121)
for param in 'abxyps':
print param, '=>', getattr(f, param)