4 ms·

nice. I assume, still, it should not be used to store JTW refresh tokens, or anything where secure storage is required.

geofft 8y ago
I don't see why not - at least if you're comfortable with client-side code on the website having access (implicit or explicit) to the token. Certainly nothing you store on the client side is secure against an untrusted user, so you should only store the user's own secrets, not things you wish to keep secret from the user. And anything you intend to make use of fro the client side must be usable from within the website, so anyone who can get code execution on the website (e.g., via XSS) has already gained access to whatever you're trying to protect. I see a handful of blog posts on the internet arguing that HttpOnly cookies are a more secure storage place than web storage, because HttpOnly cookies are only vulnerable to CSRF attacks and not XSS and CSRF is easier to defend against. This argument is, as far as I can tell, completely flawed: if an attacker is able to execute XSS, they're then able to use that XSS to execute same-site forged requests - they no longer have to bother with the "cross-site" part of CSRF. They can just fetch your anti-CSRF token with a normal XHR after having executed an XSS, and then they can make arbitrary same-origin requests against your website, each of which gets sent with the HttpOnly cookie.
- platform 8y ago
  JWT refresh tokens are equivalent to passwords. (they are active for days at a time). I do not know of many web apps that store passwords in browser storage. Unlike passwords, JWT refresh tokens are created programmatically (not entered by user interactively). Perhaps,I am just missing a link, but I though browsers do not allow an application to programmatically store passwords securely
  - penagwin 8y ago
    JWT tokens, and any session tokens are used for authentication, like a password. The issue is that people don't want to entire a password every single time they want to send a request that requires authentication. Imagine google/facebook/etc. prompting you for a password every time you click a link. That's what it would be like if browsers couldn't store session tokens. Typically the matching hostname can view local data/cookies though (along with any extensions you have that have access to it - which is most of them). That's why you shouldn't ever copy/paste stuff into the console of a website, it lets people extract your session.
  - api_or_ipa 8y ago
    If you don't persist JWT in localStorage or sessionStorage, how would you handle page reloads? You'd have to rely on a session cookie and get a new JWT from your auth service. You'd solve XSS but get CSRF. Storing a JWT in localstore isn't the same as storing a password in plain text. JWTs are indeed non-revocable, but they are also non-durable (ours expire after 24 hours) and cannot be renewed without a refreshToken. Most people also do not rely on JWTs to write important information (like password reset) because there are more secure alternatives for these specific use cases. As an aside, if someone gets script access to your SPA, you're already very far up shit creek. If your user types in any sensitive information like a password to login you've lost the war. Securing the JWT is the very least of your concerns at that point.
  - geofft 8y ago
    There are two important attributes of a password: they're (often) human-memorable and prone to reuse / inexact reuse on other sites, and they're a long-term authentication token. JWT refresh tokens have the second attribute. But so are many other things, like regular old cookies that don't expire for weeks or months, which browsers store on a regular basis. If you're logged into HN you have one of these. While the HN cookie is HttpOnly, this isn't really putting it in more-secure storage: an XSS attack against HN can just issue whatever API requests to HN it wants, even though it can't easily walk off with a copy of the cookie.

I don't see why not - at least if you're comfortable with client-side code on the website having access (implicit or explicit) to the token. Certainly nothing you store on the client side is secure against an untrusted user, so you should only store the user's own secrets, not things you wish to keep secret from the user. And anything you intend to make use of fro the client side must be usable from within the website, so anyone who can get code execution on the website (e.g., via XSS) has already gained access to whatever you're trying to protect. I see a handful of blog posts on the internet arguing that HttpOnly cookies are a more secure storage place than web storage, because HttpOnly cookies are only vulnerable to CSRF attacks and not XSS and CSRF is easier to defend against. This argument is, as far as I can tell, completely flawed: if an attacker is able to execute XSS, they're then able to use that XSS to execute same-site forged requests - they no longer have to bother with the "cross-site" part of CSRF. They can just fetch your anti-CSRF token with a normal XHR after having executed an XSS, and then they can make arbitrary same-origin requests against your website, each of which gets sent with the HttpOnly cookie.

platform 8y ago
JWT refresh tokens are equivalent to passwords. (they are active for days at a time). I do not know of many web apps that store passwords in browser storage. Unlike passwords, JWT refresh tokens are created programmatically (not entered by user interactively). Perhaps,I am just missing a link, but I though browsers do not allow an application to programmatically store passwords securely
- penagwin 8y ago
  JWT tokens, and any session tokens are used for authentication, like a password. The issue is that people don't want to entire a password every single time they want to send a request that requires authentication. Imagine google/facebook/etc. prompting you for a password every time you click a link. That's what it would be like if browsers couldn't store session tokens. Typically the matching hostname can view local data/cookies though (along with any extensions you have that have access to it - which is most of them). That's why you shouldn't ever copy/paste stuff into the console of a website, it lets people extract your session.
- api_or_ipa 8y ago
  If you don't persist JWT in localStorage or sessionStorage, how would you handle page reloads? You'd have to rely on a session cookie and get a new JWT from your auth service. You'd solve XSS but get CSRF. Storing a JWT in localstore isn't the same as storing a password in plain text. JWTs are indeed non-revocable, but they are also non-durable (ours expire after 24 hours) and cannot be renewed without a refreshToken. Most people also do not rely on JWTs to write important information (like password reset) because there are more secure alternatives for these specific use cases. As an aside, if someone gets script access to your SPA, you're already very far up shit creek. If your user types in any sensitive information like a password to login you've lost the war. Securing the JWT is the very least of your concerns at that point.
- geofft 8y ago
  There are two important attributes of a password: they're (often) human-memorable and prone to reuse / inexact reuse on other sites, and they're a long-term authentication token. JWT refresh tokens have the second attribute. But so are many other things, like regular old cookies that don't expire for weeks or months, which browsers store on a regular basis. If you're logged into HN you have one of these. While the HN cookie is HttpOnly, this isn't really putting it in more-secure storage: an XSS attack against HN can just issue whatever API requests to HN it wants, even though it can't easily walk off with a copy of the cookie.