I just call them one-time passcodes (otp)
Most of the time I am not using multifactor or 2factor the way it was designed
But it is accurately a one time passcode
When MFA isn't MFA, or how we got phished
91–100 of 287 posts
Re: When MFA isn't MFA, or how we got phished
#92Earlier quoted context omitted.
And obviously untrue. If you’re an employee who just caused a security incident of course you’re going to make it seem as sophisticated as possible but considering Retool has hundreds of employees from all over the world, the range of accents is going to be such that any voice will sound like that of at least one employee. Are you close enough to members of your IT team to recognise their voices but not be close enou…
Fully agreed, saying a deepfaked voice was involved without hard proof is deflecting blame by way of claiming magic was involved.
I think its right to be skeptical, but its also easy to do this if you’ve identified the employee to train on the voice of. You could even call them and get them to talk for a few minutes if you couldnt find their instagram.
Re: When MFA isn't MFA, or how we got phished
#93Earlier quoted context omitted.
>FIDO2 can also detect the domain making the request, and will not provide the correct code even it the page looks correct to a human. I could not agree more with this sentiment! We need more of this kind of automated checking going on for users. I'm tired of seeing "just check for typo's in the URL" or "make sure it's the real site!" advice given to the average user. People are not able to do this even when they kno…
The problem with Fido (and other such solutions, including smartphone-based passkeys) is that they make things extremely hard if you're poor / homeless / in an unsafe / violent family situation and therefore change devices often. It's mostly a non-issue for Silicon Valley tech employees working solely on their corporate laptops, and U2F is perfect for that use-case, but these concerns make MFA a non-starter for the w…
You're right, software security is only really available to rich and tech minded folks.
That's kind of what I was trying to get at with my previous statement about humans being tired and fallible. The way we access and protect our digital assets feels incredibly un-human to me. It's wrapped up in complexity and difficulty that is forced upon the user (or kept away from, if you want to look at it that way).
As it is now, all of the solutions are only really available to someone who can afford it (by life circumstance, device availability, internet, etc) and those who can understand all the rules they have to play by to be safe. It's a very un-ideal world to live in.
When I brought up FIDO2, I was less saying "FIDO2 is the answer" and more saying, "we need someone to revolutionize the software authentication and security landscape because it is very very flawed".
Re: When MFA isn't MFA, or how we got phished
#94Earlier quoted context omitted.
> Very sophisticated attack, I would bet most people would fall for this. No. If you think people at your company would fall for this, then IMO you have bad security training. The simple mantra of "Hang up, lookup, call back" ( https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo... ) would have prevented this. Literally like 99% of social engineering attacks would be prevented this way. Seriously, make a lit…
This fails to satisfy one of the core lessons here: trust nothing, not even your own training and culture.
So I take it you are employed by someone that allows you to connect to nothing and change nothing? Because if you can do any of those things, your employer is clearly Doing It Wrong, based on your interpretation.
(If you happen to be local-king, flip the trust direction, it ends up in the same place.)
Re: When MFA isn't MFA, or how we got phished
#95Re: When MFA isn't MFA, or how we got phished
#96Earlier quoted context omitted.
> Very sophisticated attack, I would bet most people would fall for this. No. If you think people at your company would fall for this, then IMO you have bad security training. The simple mantra of "Hang up, lookup, call back" ( https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo... ) would have prevented this. Literally like 99% of social engineering attacks would be prevented this way. Seriously, make a lit…
The ineffectiveness of "security training" is precisely why TOTP is on its way out - you couldn't even train Google employees to avoid getting compromised.
IMO most of this is because most security training I've seen is abysmal. It's usually a "check the box" exercise for some sort of compliance acronym. And, because whatever compliance frameworks usually mandate hitting lots of different areas, it basically becomes too much information that people don't really process.
That's why I really like the "Hang up, look up, call back" mantra: it's so simple. It shouldn't be a part of "security training". If corporations care about security, it should be a mantra that corporate leaders begin all company-wide meetings with. It's basically teaching people to be suspicious of any inbound requests, because in this day and age those are difficult to authenticate.
In other words, skip all the rest of "security training". Only focus on "hang up, look up, call back". Essentially all the rest of security training (things like keeping machines up to date, etc.) should be handled by automated policies anyway. And while I agree TOTP is and should be on its way out, the "hang up, look up, call back" mantra is important for requests beyond just things like securing credentials.
Re: When MFA isn't MFA, or how we got phished
#97Some startup, please make a product that uses AI to identify these obviously fake emails.
Hello A, This is B. I was trying to reach out in regards to your [payroll system] being out of sync, which we need synced for Open Enrollment, but i wasn’t able to get ahold of you. Please let me know if you have a minute. Thanks
You can also just visit https://retool.okta.com.[oauthv2.app]/authorize-client/xxx and I can double check on my end if it went through. Thanks in advance and have a good night A.
Re: When MFA isn't MFA, or how we got phished
#98Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…
In my company, such a communication would never come via a text, so that would be a red flag immediately. All such communications come via email, and we have pretty sophisticated vetting in place to ensure that no such "sketchy" emails even arrive in our inboxes in the first place. Additionally, we have a program in place which periodically "baits" us with fake phishing emails, so we're constantly on the lookout for…
After initially thinking it was a good idea, I've come to disagree pretty strongly with the idea of phish baiting employees. Telling employees not to click suspicious links is fine, but taking a step further to constantly "testing" them feels like it's placing an unfair burden on the employee. As this attack makes clear, well done targeted phishing can be pretty effective and hard for every employee to detect (and you need every employee to detect it).
Company security should be based on the assumption that someone will click a phishing link and make that not a catastrophic event rather than trying to make employees worried to ever click on anything. And has been pointed out, that seems a likely result of that sort of testing. If I get put in a penalty box for clicking on fake links from HR or IT, I'm probably going to stop clicking on real ones as well, which doesn't seem like a desirable outcome.
Re: When MFA isn't MFA, or how we got phished
#99Fantastic write-up. Major props for disclosing the details of the attack in a very accessible way. It is great that this kind of security incident post-mortem is being shared. This will help the community to level-up in many ways, specially given that its content is super accessible and not heavily leaning on tech jargon.
I disagree. I appreciate the level of detail, but I don't appreciate Retool trying to shift the blame to Google, and only putting a blurb in the end about using FIDO2. They should have been using hardware keys years ago.
Hi, I'm sorry you felt that way. "Shifting blame to Google" is absolutely not our intention, and if you have any recommendations on how to make the blog post more clear, please do let me know. (We're happy to change it so it reads less like that.)
I do agree that we should start using hardware keys (which we started last week).
The goal of this blog post was to make clear to others that Google Authenticator (through the default onboarding flow) syncs MFA codes to the cloud. This is unexpected (hence the title, "When MFA isn't MFA"), and something we think more people should be aware of.
Re: When MFA isn't MFA, or how we got phished
#100Beyond having hardware keys, this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. It's always okay to say, "actually, let me get back to you in a minute" and hang up, calling back on a known phone number from the employee directory, or communicate on different channel altogether.
Organizationally, everyone should be prepared for and encourage that kind of response as well, such that employees are never scared to say it because they're worried about a snarky/angry/aggressive response.
This also applies to non-work related calls: someone from your credit card company is calling and asking for something? Call back on the number on the back of your card.