Earlier quoted context omitted.
What’s this got to do with zero trust?
it is a cynical comment that is meant to hilite the relationship between humans where oppressive and untrusting employment leads to increase in antipathy, ill-will, feelings of being abused and all of that leading to insider theft and serious pre-meditated betrayal ?
When MFA isn't MFA, or how we got phished
51–60 of 287 posts
Re: When MFA isn't MFA, or how we got phished
#52TOTP and SMS based 2FA are NOT designed to prevent phishing. If you care about phishing use yubikeys.
Re: When MFA isn't MFA, or how we got phished
#53Very 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…
>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…
Re: When MFA isn't MFA, or how we got phished
#54Fantastic 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.
Re: When MFA isn't MFA, or how we got phished
#55Earlier quoted context omitted.
> I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone Why don't you use the printed recovery tokens?
Who has a printer these days?
Re: When MFA isn't MFA, or how we got phished
#56It's the new advanced persistent threat, a perfect phrase to divert any resposibility.
(Yes, there are deepfakes. Yes, there are APTs. This is likely neither.)
Re: When MFA isn't MFA, or how we got phished
#57Re: When MFA isn't MFA, or how we got phished
#58Very 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…
> 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…
Re: When MFA isn't MFA, or how we got phished
#59Very 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…
Re: When MFA isn't MFA, or how we got phished
#60So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system.
Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive systems like internal admin tools? I'm thinking like the "turn the two keys simultaneously to launch the missile" systems. I'm thinking it would work like the following:
1. If a system detects a user is logging into a particularly sensitive area (e.g. a secrets store), and the user is from a new device, the user first needs to log in using their creds (including any appropriate MFA).
2. In addition, another user like an admin would need to log in simultaneously and approve this access from a new device. Otherwise, the access would be denied.
I've never seen a system like this in production, and I'm curious why it isn't more prevalent when I think it should be the default for accessing highly sensitive apps in a corporate environment.