Trust Me, Bro

It’s time to log in to the system to do the thing. For some reason you’re going through a secondary channel — perhaps you’re using a command-line tool, perhaps it’s a third-party app, perhaps it’s a plugin for your browser or text or image editor. Maybe you’re using a personal finance tool that wants to log in to your bank. Logging in via this channel prompts for your username and password, and you oblige.

Sometime later, you find that something involved in this channel — maybe the browser/editor had a security flaw, maybe the third-party app was sold to a nefarious party — has taken over your account.

Whatever the excuse, gone are the days when we should simply give out our canonical passwords to any ol’ app we want to try out. While there was a time when this was normal practice — logging into email before webmail with our favorite client, checking up on our favorite USENET groups with your newsreader; the 90s internet was a time of trustful naïveté — those days are no more.

It may seem at first glance that the real job is merely a matter of educating people not to trust their credentials to anything that asks for them, but Apple, Google, and others have taken a more proactive approach: the app-specific password. Many other systems use OpenID Connect (OIDC) to enable all sorts of software client applications to authenticate with them, and some use Device Flow Grants.

Unfortunately these alternative patterns are not as common as they perhaps could or should be. Banking & personal finance is perhaps the most notable example of this: people want to get at their financial data through apps, but because there are so many banks and few have APIs let alone any kind of coherent third-party app authentication strategy, services like Plaid fill the vacuum by asking for your credentials and scraping your bank’s website.

Maybe you trust a too big to fail service such as Plaid with your banking credentials, maybe you don’t, maybe you think no one should, and maybe you think any concern is overblown. Regardless, what their use of this pattern accomplishes is legitimizing it in other contexts. It’s not that big of a leap for the less-savvy to jump to the conclusion of “well if it’s OK to do this with my bank, it must be ok for other things”. There is open banking, though some banks are taking the opportunity to skip the middleman and sell API access to personal finance apps directly.

If you manage a system people can log in to, you might say well, we don’t have any third party clients and we’re not going to allow any, so we don’t have to worry about it, but it’s not going to stop people from trying. What are you doing to prevent scraping? It’s a lot of work being the cat, catching mice in this game.

If you manage a system people can log in to, you might also say, well, it’s an official plugin for this (browser, editor, etc), so it’s ok, to which: are you sure you can trust the security of that environment? Both browser extensions and text editor plugins are wide targets for malicious actors, so you’re trusting the host environment to keep your users’ credentials safe. But when Microsoft breaks something as fundamental as clipboard paste in VSCode, how much do you really want to trust that host environment? If there was a problem, wouldn’t it be nice to isolate it to just the affected credentials?

A nice feature of these context-specific authentication methods is giving you the ability to revoke specific credentials without having to revoke all of them. It’s the difference between making copies of the same physical key for everyone and instead giving out proximity cards that can be managed individually, and while I can clone or copy my own proximity cards, I know they all trace back to me.

If your system provides data that people might want to access in other contexts, you need to have a strategy for dealing with it that goes beyond sticking your head in the sand. Plan early, before it becomes a problem.