Justifiable in a vacuum, but the end result is grandma knows "sometimes it's OK to give the code to the person on the phone"
They should have users receive the code and then submit said code into the application for verification, with clear instructions that this code is produced as a result of a support call, and to confirm you are on an existing call when submitting the code. Doing so would not force users to divulge codes over the phone, and enable support staff to verify identity all without training users that reading codes over the p…
A few reminders bear repeating: — no support group from a big company is going to call you. Ever. — never give out codes sent to use via sms or push notifications to someone requesting them via phone or email. Never. The messages often even say that! — Don’t put all your private info behind one password, so don’t use Google Authenticator backed by your Google Account as your password manager. Always use a third party…
Except that a few weeks ago, I got a phone call - from a number with no results on Kagi search - claiming to be the online banking support of my bank - asking me to read them a code sent to me via SMS and when I refused to do that, they blocked my login credentials for online banking and sent me a sternly worded (paper) letter that my account could not be upgraded automatically for their software system migration bec…
I've gotten calls from my bank before, where they tried to get me to authenticate after I answered the phone. I said "look, you called me, I'd be crazy to just answer the phone and give out personal info." They refused to provide any info that I could have used to validate that they were legit (like telling me something about my account number, when my account was created, etc.). They said I had to authenticate with them before they would tell me anything.
Sometimes the rep is understanding, and acknowledges that he would have the same reaction, but other times it's like they don't realize they're asking their customers to do something Very Stupid™.
Does anyone know how the email from (or appearing to be from) @google.com works? Wouldn't the Apple account reject it because it fails DKIM/etc?
I've received a phishing email from an @paypal.com email address. (The From: header showed an @paypal.com email address.) Fortunately, the text of the email itself was fishy enough to make me realise it wasn't legitimate. I have no idea how it passed spam filters. I reported the email to both PayPal and my email provider, and I never heard back.
Can you download the email as EML and paste the content here?
I’ve personally never had that happen. It should go on a name and shame list.
>I’ve personally never had that happen. It should go on a name and shame list The key situation for giving out an SMS code that the gp is pointing out is the customer initiates the call to the support center . For example, suppose somebody wants to add a credit-card to their smartphone digital wallet. They have to call the bank issuing their credit-card to do that . Once the customer support person answers the call,…
The signin 2SV SMS verbiage used by Chase is: "Chase: DON'T share. Use code 12345678 to confirm you're signing in. We'll NEVER call to ask for this code. Call us if you didn't request it."
I assume in the case where the customer initiates the call and support is verifying their identity via SMS, they use different text (i.e. not "to confirm you're signing in"). Otherwise, that'd be pretty ridiculous.
The risk of not syncing — when you lose/reset your phone, so does your OTP app. If you don't have backup codes saved, you're cooked.
> The risk of not syncing — when you lose/reset your phone, so does your OTP app. If you don't have backup codes saved, you're cooked. Most clued-up places enable you to register a Yubikey as 2FA. So then it doesn't matter if you loose your OTP app and your backup codes because you've still got a Yubikey. (And those that don't allow Yubikey, almost certainly will have SMS as a secondary option).
> Most clued-up places enable you to register a Yubikey as 2FA. So then it doesn't matter if you loose your OTP app and your backup codes because you've still got a Yubikey.
And what happens if you lose your Yubikey or it stops working? You're back to needing backup codes or an additional 2FA device
Does anyone know how the email from (or appearing to be from) @google.com works? Wouldn't the Apple account reject it because it fails DKIM/etc?
They probably sent it from gmail which would pass the SPF check (google.com and gmail.com have the same SPF). They wouldn't have it signed to pass DKIM, but google doesn't use strict alignment checking so to pass DMARC either SPF or DKIM are acceptable. ~ dig _dmarc.google.com txt +short "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
I'm pretty confident gmail's servers don't let you send with headers matching @google.com email addresses you don't control though.
>I’ve personally never had that happen. It should go on a name and shame list The key situation for giving out an SMS code that the gp is pointing out is the customer initiates the call to the support center . For example, suppose somebody wants to add a credit-card to their smartphone digital wallet. They have to call the bank issuing their credit-card to do that . Once the customer support person answers the call,…
Justifiable in a vacuum, but the end result is grandma knows "sometimes it's OK to give the code to the person on the phone"
How else are you supposed to do identify verification over the phone?
I think if the war against phishing online has taught us anything, it's that humans can't be trusted to not reveal secrets to scammers. Only machine-to-machine public key authentication (like TLS or WebAuthn or U2F) is truly phish-proof.
Literally got something similar to this last Friday. Sounded legit. My one weird trick that works every time - give me a ticket # and an official phone number to call back to and I can confirm the phone number is legit. This way you can continue the conversation if it is actually legit, and if it's not legit then all good. The guy who called me said "I can send you an email to show it's official" and I thought of tha…
I have no time and energy for the level of paranoia present web services RQUIRE. I started to cut back. One of the firsts: not accepting Terms and Conditions for a site my company delegated for the sole purpose of delivering my payslips (probably some others too, but marginal compared to this). I'd need to revisit the details to tell what was that exactly, but some sort of sharing some of my data with thrid party (subcontractor) thing. It is a recent develpment, I will see how it flies with my organization, but I'd be surprised if I could be forced to accept T&C just for receiving payslips. We have 2 other admin accounts for reporting time, absence, no more for me with some arbitrary service provider, thanks. (in the previous job of mine our absence tracking system sent me incentivised ads in the dashboard to attract others to their platform and some sort of weird discount system if I buy things here or there, quite repelling)