Hacker News new | past | comments | ask | show | jobs | submit login

This is false, a gross oversimplification. Every organization has complexities, it doesn't reduce to a common idiocy. Even when the net result is idiotic in hindsight.



[flagged]


It sounds like you're experience has been at a small firm. At scale, 2fa and yubikeys are a no brainer with regard to risk vs reward/ safety.

Do you think all security engineers or whatever you want to call them are total incompetent idiots? If yes, I can't help you. If no, then you don't need further explanation from me.

Security requires a complex balancing act, and in this case they got it wrong, end of story. As stated elsewhere in this thread, there are only those who've been breached and those who don't know they've been. End of story.


Corporate security teams are built on three different traditions:

1. The policy/compliance tradition - the kind of people who looked at PCI-DSS and decided that was what they wanted to devote their life to. The accountants of the tech world. You've got resources and want to roll out U2F? That's not in the policy document, we'd rather spend the resources on this great audit of our suppliers' compliance that I've been planning....

2. The be-lazy-be-popular tradition - for the team that hires a guy to reduce other people's workload, not increase it. Resources to roll out U2F? I won't stop you if you've got the money to spend, but what we've got is probably enough - a lot of companies don't use U2F, you know.

3. The hacker tradition - the kind of people who see every real, exploitable vulnerability they find as proof of their 1337 status. They don't care if a policy document says you should disable paste, that's bad advice, don't do it. Rolling out U2F sounds like a great idea - but a lot of corporate environments will chase these types out, or curb their enthusiasm by ignoring their reports.

Perhaps kirbys-memeteam worked in companies with security teams that tended more towards traditions 1 and 2, while your employer's security team had more of tradition 3?


[flagged]


The bigcorps don't make exceptions for Tiny Tony's. If you work at these sorts of firms, you should probably start an anonymous exposé blog, it would be enlightening for the rest of us. It would also probably help get things fixed so they could avoid further embarrassment before it becomes a real problem (like in this case).

I bet you could make a fair sum from the ad impressions alone, and feel good knowing you were acting as the force multiplier for positive change.

Edit: Your personal jabs aren't in the spirit of a collaborative or curious conversation. You've revealed yourself as just another 007 wannabe. Boring.


Explain why what is false? You're just making vague claims about anecdotal experiences. It seems unlikely, in general, that a security team would not support a Yubikey rollout. Even one that only cares about compliance would likely support it because it will make compliance easier - auditors care a lot about phishing and if you can say "OK, yeah, we had some users fail the phishing test again BUT our 2FA is phish-proof" that's an easier conversation.

I'm sure there are truly lazy and incompetent security teams out there but it makes no sense that they would be the majority or even particularly prevalent. Maybe you're just unlucky and ran into one, or maybe there were real reasons why a Yubikey rollout wouldn't work;

a) Who's going to ship the keys? Yubico provides services for that, will you use those? Pay for them?

b) Who's paying for this? Did your infra team ask the security team to pay for it? Who's paying for replacements and support?

c) Is this a high priority for the team vs other issues?

d) Do all of your vendors support Yubikeys or are you going to have to have a hybrid solution? What will migration from vendors configured for some other FMA solution to Yubikeys look like?

I support a rollout at any company, for the record, but these vague statements with the conclusion of "security people don't care" leave a lot to be desired.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: