Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hardly an SMS issue, an issue with a vendor not properly securing a sensitive datastore.


It is an SMS issue in the sense that OTPs and hardware tokens don't require their rotating secrets to be written to some potentially publically-readable datastore. This specific attack vector simply does not exist for those technologies.


I don't see why SMS would need to write to a store, public or not. One can implement SMS-2FA using TOTP for example, it's just that the TOTP secret is not shared with the recipient.


Yes, it is not a technical necessity to store these messages. But there is the option to do it (and some people are evidently doing it). The point is that for one-time-passwords, it's not even an option, not matter how hard you try. You simply cannot make this class of mistake. Unless you try really really hard to fuck up and, say, for some very weird reason, exfiltrate the one-time passwords generated on the user's device every few seconds.


How does the bank verify the OTP generated on the user's device?


What if my OTP base data is exported to a publically-readable datastore? I could be tricked into exporting the QR codes from Google Authenticator, for example. Though I see that there are significantly better 2FA methods, it does seem like the biggest flaws with SMS 2FA are in the insecure implementations, not the actual concept.


Okay, but the transport layer (SMS) is independent of the issue here. Email, push, even carrier pidgeon OTPs would suffer the same issue.

Also, storing secrets is day to day life in a lot of scenarios.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: