Possible issue with localStorage

[GreenFootballs]

I've noticed that the Bluesky web app uses localStorage for user profile info and other things, but I also see the API access and refresh tokens in that root item. Are they supposed to be there? Seems like this could be a security problem because browser extensions can easily view the contents of localStorage, and potentially hijack a user's tokens. Am I missing something that would prevent this?

[snarfed]

This isn't really specific to Bluesky as much as just the overal browser extension security model, specifically host permissions, functionality permissions, and browsers' same-origin policy. When you install a browser extension, it asks you for the permissions it needs, including the sites and functionality it needs access to. Those may give it access to read those sites' cookies, run content scripts in their origins, to read their localStorage, etc. So if you grant a browser extension access to google.com or facebook.com and cookies or storage, it can often get your credentials for those sites too.

Some details here have changed between manifest v2 and v3, some significantly, but the overall security model is still roughly the same.

[GreenFootballs]

Yes, I understand very well how all of that works. My point is that sensitive data like API access/refresh tokens should never be accessible in the client. Pretty basic security practice.

[snarfed]

Huh. Clients pretty much always need creds, right? Desktop and mobile apps store them, they're in cookies for logged in user sessions on web sites, and fully client side JS apps like bsky.app generally store them in localStorage. Maybe I'm misunderstanding the problem you're describing. Are you proposing that logins shouldn't be stored across sessions in general? Or that they should be stored somewhere else, like in a TPM?

[snarfed]

Maybe a better way to rephrase would be, if they want to give users the option to stay logged in across browser restarts - like most web sites - do you have a proposal for where they should store session creds besides localStorage or cookies?

[GreenFootballs]

Please read this: https://hackernoon.com/improve-the-security-of-api-keys-v5kp3wdu

There are ways to secure API keys without leaving them visible to a third party like a browser extension (for one example). When you have API tokens in localStorage in plaintext, it's extremely simple for a bad actor to hijack a user's session. In the case of Bluesky, since there's no oAuth yet to restrict permissions, this would give them total unrestricted access to the user's account.

[snarfed]

Ah! Thanks for the link to the article, I think I see the confusion now.

That article discusses API keys, which are long-lived identifiers and credentials for entire apps. For example, if I want to use the GitHub API, I create an app (aka API client) in the GitHub UI, they give me an API key (generally a client id/secret pair), and I then use that API key with all of my app's API requests, across all users. Often this is just during their initial OAuth flows, but sometimes elsewhere too.

What you're seeing in browser localStorage for bsky.app isn't API keys, it's access tokens (and refresh tokens). These are short-lived, per-user credentials. In this case, they're basically the same as session cookies that browsers store for web sites you're logged into. Storing these in cookies and/or localStorage is very standard practice.

Apologies if you already know much or all of this! And you're absolutely right, API keys ideally shouldn't be stored on user devices, since the risks are significantly higher than with short-lived, per-user tokens. The article does mention access tokens too, and how they're different. Otherwise, its advice generally seems good! (Afaik the state of the art for protecting API keys on devices is PKCE, the OAuth2 flow for device-native apps, and specific JWT techniques, which the article mentions.)

[GreenFootballs]

But again... the localStorage item for Bluesky has not only the access token, it also has the refresh token. So it's not just a short-lived token we're talking about, since it can be refreshed. And again, even if someone could only get access for a short time, they have complete control of the user's account at that point and can do a lot of damage if they're malicious.

Yes, I already do know more than a little about keeping access tokens out of public view, which is why I'm bringing up this point for discussion. Keeping API access and refresh tokens in a place the general internet can see is simply a bad practice -- again, unless I'm missing a security measure that isn't obvious.

[snarfed]

Threat model is important here. You're right, keeping access tokens in a place the general internet can see would definitely be bad practice! Fortunately, the general internet cannot see your browser's localStorage. The threat model here is a browser extension that the user has explicitly granted access to both Bluesky's storage and creds and the ability to send network requests to the browser extension's own server. Both of those show up in the approval prompt, and the user has to explicitly approve them.

(If your threat model is some other attacker that somehow has full remote access to your device and its local storage, that's extremely difficult to defend against in any way, TPMs notwithstanding. If that happens, your Bluesky account is the least of your worries. 😀)

Having said that, you're definitely right that browser extensions have their downsides security wise! Google and Mozilla do regularly find and take down malware in their extension directories. And users aren't always as careful with permission prompts as we'd like. (Which often isn't their fault.)

However, there are valid use cases for a browser extension to access and use your Bluesky credentials. For example, when you're on a personal web site or Twitter profile, an extension could show you whether that person is also on Bluesky. You might not choose to install that extension, but other people might. That tradeoff between security safeguards and user freedom has been at the core of browser extensions and specifically the manifest v3 debates over the past few years.

(And yes, refresh tokens have longer lifespans than access tokens, but still finite and limited. API keys, on the other hand, generally don't expire at all.)

[snarfed]

Maybe more importantly, again, storing user creds in localStorage or cookies is standard practice for web apps. Do you have an alternative proposal for where bsky.app should store its user creds (tokens)?

The options I see are keeping them in memory only, which means the user would have to log in again every time the browser restarts or its service worker gets unloaded, or obfuscating them, which only adds friction. Determined attackers would still manage to de-obfuscate them. bsky.app could encrypt the tokens, but it would need to store the encryption key somewhere, which has the exact same problem.

(The techniques in the article don't apply here because the threat model is different. They're trying to protect API keys from users, who do have full access to their device and disk.)

If you have a truly better solution, you might be able to improve security for a huge swathe of the tech industry!

[GreenFootballs]

I'm going to drop this until someone who's actually involved in the development side of Bluesky weighs in. Thanks for your input.

[snarfed]

Sorry for coming on so strong, thank you for being so decent. I guess I've always taken all this as gospel, so I was surprised and intrigued to hear there might be another way. That probably got me carried away.

[dholms]

Hey @GreenFootballs thanks for raising the concern. Browser extensions are in general are rife with security complications. They could also, for instance, log your key strikes to find your password.

Unfortunately, as @snarfed pointed out, user credentials do need to be stored somewhere accessible by the application & generally if it's accessible by the application, it's also accessible by XSS attacks or malicious browser extensions.

One step we take to guard against attacks is to rotate your refresh token every time you get a new access token. This means that refresh tokens are short-lived as the current refresh token is invalidated every time you get a new access token.

These things evolve of course, but I would say it's industry standard to store refresh tokens for SPAs in local storage (here's an auth0 blog post on the topic) with the caveat that you should be rotating your refresh token (which we are).

I'm curious what alternatives you might recommend?

[snarfed]

Interesting! Refresh token rotation is new to me, as is the silent authentication technique they mention there. Thanks!

[shivkr6]

Why not use expo-secure-store for storing access and refresh tokens in mobile?

[GreenFootballs]

Yes, it was new to me as well! That's what I meant by "a security measure that isn't obvious." This does go a long way toward mitigating the token hijacking issue if I understand it correctly. I plan on experimenting with it a bit.

In my own projects I never have API tokens in a web client; I usually use a session token that authenticates the user with the server, and all the API calls are proxied server-side, so that tokens are never exposed to the web at all.

Thanks for the replies.

[DavidBuchanan314]

iiuc, OAuth can/will fix this, if clients implement DPoP using non-extractable WebCrypto keys