{"id":28038,"date":"2020-02-04T15:34:51","date_gmt":"2020-02-04T20:34:51","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28038"},"modified":"2021-07-03T14:16:02","modified_gmt":"2021-07-03T18:16:02","slug":"delivering-origin-bound-one-time-codes-over-sms","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/02\/04\/delivering-origin-bound-one-time-codes-over-sms\/","title":{"rendered":"Delivering Origin-bound One-time Codes Over SMS"},"content":{"rendered":"

Ricky Mondello<\/a>:<\/p>\n

\n

We’ve published an explainer about an idea to harden SMS-delivered one-time passwords by allowing senders to associate the codes with a website. We’ve been talking about the idea with some folks at Google, and would like more feedback.<\/p>\n<\/blockquote>\n\n

WebKit<\/a> (MacRumors<\/a>):<\/p>\n

This proposal attempts to reduce some of the risks associated with SMS delivery of one-time codes. It does not attempt to reduce or solve all of them. For instance, it doesn’t solve the SMS delivery hijacking risk, but it does attempt to reduce the phishing risk.<\/p>

[…]<\/p>\n

But because there is no standard text format for SMS delivery of one-time codes, systems which want to make programmatic use of such codes must rely on heuristics, both to locate the code in the message and to associate the code with a website. Heuristics are prone to failure and may even be hazardous.<\/p>\n

[…]<\/p>\n

To address this, we propose a lightweight text format that services\nmay adopt for such messages. It’s about as simple as it gets. It begins\nwith (optional) human-readable text. After the human-readable text both\nthe code and the origin appear on a single line, with sigils denoting\nwhich is which. This is the last line of the text.<\/p><\/blockquote>\n\n

Previously:<\/p>\n