3 ms·
> some 2FA do not seem to think it is critical to send the email or txt msg right away, and even when they do, email servers do not really work real time SMS i
by creshal 10y ago
> some 2FA do not seem to think it is critical to send the email or txt msg right away, and even when they do, email servers do not really work real time
SMS isn't real time either, it's best effort. Mostly (~99,9%) it gets through within seconds, but delays of a few minutes are perfectly acceptable to telcos. As service provider you can't do much about it, either pay through the nose for "priority" delivery (which maybe halves the amount of delayed messages in our experience) or tell your customers to switch mobile providers (yeah, good luck with that).
- scrollaway 10y agoAs a service provider there is something you can do about it: Use well known out-of-band 2FA specs such as TOTP. Those are compatible with Google Authenticator and don't require a phone number, which is a massive inconvenience (not always available, not available in every country, SMS not reliable, requires an ID, not free, leaks personal information to the service provider, ...)
- creshal 10y agoWell, yeah. We're not using SMS for 2FA, just for delivering monitoring alerts. With those reliability statistics (and the impossibility to improve it) I wouldn't do SMS-based 2FA at all.
- dboreham 10y agoWe've found other interesting behavior in email-to-SMS services using it for alerts (this is in the US): Verizon: will deliver all messages typically with low latency. AT&T: Variable delivery latency and they have some sort of rate-limiting where if your system generates 10 alert messages within a short period, they queue them up for a couple of hours! Inmarsat: Fast consistent delivery but they have an undocumented rate cap that when reached results in all (all!) messages being black-holed for 30 days. There is no way to reset this state. The cap is something 150 messages per month or 5 per 10 minute period.