Yeah, I hate extreme opinions that say not to do something just because it's not 100% effective. It's like saying don't bother using a lock because all locks can be picked and cut anyway.
I consulted to an organisation that spent multiple years refusing to allow any form of MFA.
Everyone agreed it was extremely important and some password protected data was very sensitive. But the conversation about authenticator apps always got bogged down with risks about malware on phones. I would get asked "will you stake your career on it never happening?" Of course not. Therefore "for security reasons" we never supported authenticator apps. Of course it was pointed out that people might lose hardware tokens, so they didn't happen either. Because mobile MFA isn't perfect, I had directives to stick with easily phished passwords for years.
> I would get asked "will you stake your career on it never happening?" Of course not.
"Let's make a bet over whether a customer reports an authenticator app gets hacked before a customer's account without an authenticator is broken into. If the authenticator app is hacked first, I'll resign. If an account with no 2FA is compromised, you resign."
This is probably just meant to be a joke, but I have been in that situation before and I don't think offering to gamble away your job would be an effective way to convince others to accept your advice on risk management. I still don't know how to effectively convince others to take on new risks in order to avoid bigger risks presented by the status quo. Given the additional risk that my risk assessment is deficient, doing nothing is usually the easier decision.
I still don't know how to effectively convince others to take on new risks in order to avoid bigger risks presented by the status quo.
I think you just need to be talking to someone who can understand the risks you convey, has the responsibility for both risks and the authority to effect the necessary change.
IME that's straightforward in most small companies and in large government departments it's rarely one person but multiple committees of people who you'd never be able to explain the risks to and who won't make a decision.
It's meant to be talking trash online, so you're right to take it with a grain of salt.
But I'll stand behind the view that when ideas are being shot down with challenges like "would you stake your career on this" then a bull-headed approach is worth a try.
> I don't think offering to gamble away your job would be an effective way to convince others to accept your advice on risk management.
It won't persuade technically minded people, but it tells decision makers that you're confident, and offers them a measure of accountability.
> I would get asked "will you stake your career on it never happening?"
Was anyone being asked to stake their career on all the existing security practices? I've worked on a couple of projects with politics similar to what you described, yet they had encrypted (unsalted, decryptable) passwords in a database, and only about 3 tech people seemed to understand the implications of that.
That's implying there are consequences for dire mistakes, which I don't think has been demonstrated so far. In fact, I'd almost say there are barely any consequences at all.
And, to be clear, using them for sessions is not one of those intended use cases, as joepie91 is arguing in that article. Using an actual server-side solution is easier and safer.
Mongo is the wrong choice for a solid 75% of the places it's used. In the vast majority of cases, it was brought in to replace a relational db because developers though it would be faster to not have a schema / constraints / relationships, etc. It usually lets you develop faster, at the cost of blowing up in your face a few months/years down the line, when you have to rebuild your app to use a real database because your devs remembered why relational dbs are useful in the first place.
Mongo is a document store, not a relational db. Mongo is a good choice if you're looking to replace ElasticSearch, not if you're looking to replace MySQL.
Nowadays not much, but it used to be overrated and had serious reliability problems.
Your startup probably doesn't need Big Data (TM). Just use a relational database like Postgres and learn a bit of SQL. IIRC, Postgres outperformed Mongo at JSON processing, which was supposed to be one of the stronger points of MongoDB.
That is exactly why I don't use a lock on my house. Obviously, I can't keep any stuff in my house - my belongings are strategically buried around the tri-state area, it takes me about three hours to dig up my clothes ever morning - but the peace of mind is definitely worth it.
Sure, I went on holiday to Jacksonville - thought I would take in some culture - and the copper was stripped out of my house. But they can only rob you once ;) I go number two in a field a few miles out of town now...total peace of mind.
Everyone agreed it was extremely important and some password protected data was very sensitive. But the conversation about authenticator apps always got bogged down with risks about malware on phones. I would get asked "will you stake your career on it never happening?" Of course not. Therefore "for security reasons" we never supported authenticator apps. Of course it was pointed out that people might lose hardware tokens, so they didn't happen either. Because mobile MFA isn't perfect, I had directives to stick with easily phished passwords for years.