3 ms·

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies an

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password 2. Web client receives a a generated API key and secret, which expires in a week/month/whatever. 3. That API key and secret gets stored in localstorage on the client-side by the web app for future use (as long as they're logged in) 4. Web client includes the API key and header in requests to the HTTPS backend of the app. Of course, there are more specifics that could be added like device fingerprinting, invaliding old web-created tokens when a new one is created, and classifying api keys/secrets to certain devices, but I think those things are ancillary. This is obviously very very close to what a cookie would be, and the only way I could see it going catastrophically wrong is the browser being compromised (whether the vector is XSS, or some other leaky surface on the user's computer). Regular cookies and JWT have the same issues. I can't think of a failure mode that's any worse than HTTPS cookies or JWT, and it is dead simple. I've really been trying to find some flaws in that plan lately but I can't.

mkohlmyr 10y ago
Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 1. You have to write code to provide the authentication values in all requests. 2. The GET request for the initial page render can't possibly be authenticated. Why not cookies? Other than that I agree. I really don't see the point of following the JWT spec or using an implementation of it when it has been shown that these implementations are poor (problems with none algorithm & asymmetric keys). Fundamentally, what we are talking about is simply a claimed identity, verified and signed by your backend. This is a sound principle. Just implement that and your attack surface is considerably smaller.
- hardwaresofton 10y ago
  The reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client... OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage_.28a.k.a._Offline_Storage.2C_Web_Storage.29 https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...) but the stated reasons are kind of vague/I'm not sure the reasoning is sound. If someone has physical access to the machine, all bets are off, and if a XSS vuln happens, pretty sure people can get whatever information they're looking for (including the cookie) anyway. The only real objection was the inability to restrict to HTTPS (path based, everything is just based on same origin regardless of scheme I think), however same origin policy still applies like normal. I wasn't trying to recommend localstorage over cookies, more like just trying to see if there's any huge blindspot I was missing, everywhere I look says not to do this, but the reasons were never very satisfying.
methyl 10y ago
The biggest flaw for me is that any 3rd party script can access your localstorage without your knowledge, while it can't access HTTPonly cookies.
- hardwaresofton 10y ago
  Thanks that's a valid point -- I previously misunderstood the HTTPonly cookie setting to mean restricting the cookie to HTTPS, but that's path-based restriction just now read about HTTPonly (https://www.owasp.org/index.php/HttpOnly https://www.owasp.org/index.php/HttpOnly). To be honest though, once there's an unauthorized 3rd party script running on your page, that's a pretty dire already though. I guess it's possible to also protect a little from malicious web addons/extensions though.
mspradley 10y ago
It requires looking up the secret on the backend. The JWT doesn't require that.

mkohlmyr 10y ago

Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 1. You have to write code to provide the authentication values in all requests. 2. The GET request for the initial page render can't possibly be authenticated. Why not cookies? Other than that I agree. I really don't see the point of following the JWT spec or using an implementation of it when it has been shown that these implementations are poor (problems with none algorithm & asymmetric keys). Fundamentally, what we are talking about is simply a claimed identity, verified and signed by your backend. This is a sound principle. Just implement that and your attack surface is considerably smaller.

hardwaresofton 10y ago
The reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client... OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage_.28a.k.a._Offline_Storage.2C_Web_Storage.29 https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...) but the stated reasons are kind of vague/I'm not sure the reasoning is sound. If someone has physical access to the machine, all bets are off, and if a XSS vuln happens, pretty sure people can get whatever information they're looking for (including the cookie) anyway. The only real objection was the inability to restrict to HTTPS (path based, everything is just based on same origin regardless of scheme I think), however same origin policy still applies like normal. I wasn't trying to recommend localstorage over cookies, more like just trying to see if there's any huge blindspot I was missing, everywhere I look says not to do this, but the reasons were never very satisfying.

methyl 10y ago

The biggest flaw for me is that any 3rd party script can access your localstorage without your knowledge, while it can't access HTTPonly cookies.

hardwaresofton 10y ago
Thanks that's a valid point -- I previously misunderstood the HTTPonly cookie setting to mean restricting the cookie to HTTPS, but that's path-based restriction just now read about HTTPonly (https://www.owasp.org/index.php/HttpOnly https://www.owasp.org/index.php/HttpOnly). To be honest though, once there's an unauthorized 3rd party script running on your page, that's a pretty dire already though. I guess it's possible to also protect a little from malicious web addons/extensions though.

mspradley 10y ago

It requires looking up the secret on the backend. The JWT doesn't require that.