This is called two factor auth. SMS is not considered a secure method of transport (mostly due to porting). It only solves opportunistic password compromise via password dumps.
In reality it solves far more than that for the average system for the average user. No on in reality is having their mobile number socially engineered to get into startup xs system. It's a good place to start until you are at a scale where you would have dedicated security engineers to work on the problem.
> No on in reality is having their mobile number socially engineered to get into startup xs system.
The problem is that you can't know whether that's the case at start, at some point in the future, or never. You'll only find out that your guess was wrong when you're breached which is never a good time for any service, particularly one covered by HIPAA. Besides, why intentionally implement a known-to-be-insecure second factor method? This is brand new code; there's no need to incur technical debt from day one. Which leads to:
> It's a good place to start until you are at a scale where you would have dedicated security engineers to work on the problem.
Except that day never comes for a variety of reasons. "Users already expect it so we can't remove that." "There are several dozen other security audits/features/fixes we need to make, let's prioritize those first." "What? SMS is insecure? Weird, never knew that."
Also, if we don't start making the decision now, before the second factor is ever implemented, to move away from using SMS as that second factor for the reasons it is known to be broken, when do we start?
I only “know” the code it gave me for what, a few seconds? If at all... macOS now automatically copies them from texts and 1PW automatically copies TOTPs for relevant logins to the pasteboard. I think the “know” part is something _you_ create/control and use over many instances.
