>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, a common security verification (e.g. Chase Bank does this) is for them to send you a 6 digit code to your phone. You then repeat this code back to the support person on the call. They want proof of your identity and also proof that you physically have the smartphone with you. Repeating the SMS code to the customer support person is safe because the customer called the official 1-800 number on the back of their card.
That's a totally different sequence of steps from receiving a random call from somebody claiming they are from Chase Bank. Yes, in those cases, you never give out SMS codes to that untrusted person on the phone.
Note, however, that those are two "totally different sequences of steps" to you and I, and "completely analogous / equivalent sequences of steps" to my father in law :-/
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 phone is acceptable.
Still not foolproof. Attacker can MITM the connection by initiating their own call to the real support line and relaying instructions between the user and support.
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.
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.
My reply involved the effort of sending a test message from my Chase account, to capture the exact text used. If you want people to engage with you in good faith, you should put similar effort into your replies, rather than just use Reddit-speak for "I think you're wrong."
Chase did this to me. A million alarm bells but even after hanging up and restarting the conversation from a phone number publicly listed on their website as a support contact they still did it. Wild.
Stripe Support does it for certain specific cases (email & phone). However, whenever they do it, it's a bilateral code generation: The support agent also gets a code they have to read out to the end user, which is featured prominently to them, saying the agent will have to read it out to get authentified.
Also me. Every 10 years my domains expire, and I can just pay a few hundred bucks again and forget about it, or I can do a bunch of work to move them somewhere and adjust A records and fuck around with stuff I don't remember and potentially have downtime.
IAM permissions are almost always a pain to get right but they can be so useful when you can create an API key with permissions to do only exactly what it needs to do.
