54

Personally I see no issue with using local storage as long as you are happy with the user not having to re-authenticate between sessions. The linked answer provides the following argument against this. I would argue it is very weak - Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application ...


28

How bizarre! I asked basically the same question about a month ago. In the end, we decided that using localstorage for the JWT token was ok, as long as we also did the following on the HTTP level: Ensure the entire site was served over HTTPS Ensure the use of HSTS Ensure that, once live, only the actual redirect URL was included in the Auth0 rules, as well ...


27

It's a bug in their web site, and such bugs are fairly common. They're usually something like the result of an incorrectly copied session cookie, a corrupted cache, or other programming bug. In order, this is how I'd respond: Log out of the site immediately with the "log out" button. EDIT: If given the option, click "log out on all devices.&...


14

The reason local storage is considered unsafe is because any JavaScript that executes in the context of the page can access this. This opens you up to session hijacking via reflective XSS and stored XSS vulnerabilities, potentially information disclosure depending on the contents of your token. For example: If a user goes to a page with shared content ...


10

A page which is secured with SSL (or TLS for that matter) cannot be accessed via HTTP, as that would mean that the page is not secured anymore. If I rephrase the question: Is it possible to access a particular page of a HTTPS secured website via HTTP, then I would say that is possible, but very INsecure. Moreover, the cookie with the session ID will ...


6

Well it depends. If you have an XSS vulnerability within your application an attacker can extract and use the JWT from your local storage. A method I've used and I think Auth0 indicate is to use the cookie as the JWT storage and use the flags HTTP Only and Secure this way if you have an XSS vulnerability the cookie cannot be read and is only transported in ...


6

The user can modify and delete anything stored in their browser. Any malware installed in the user's system with the user's privilege can also do so. The system administrator can also modify and delete anything stored in any user's browser. Any malware with the administrator's privilege can do the same. Another non privileged user in the same system ...


6

Well, according to PhoneGap/Cordova security guide it seems that localstorage is not recommend to store sensitive data. So what you can do? Well, here are two options I think you can use. 1- Encrypt the refresh token and store it encrypted in the localstorage. You can use CryptoJS (a JS library to encrypt/decrypt the data) to encrypt your token using AES (...


5

I'd recommend simply encrypting the file while it's being uploaded, and before it's written to disk. i.e. encrypt the file while it's being streamed. Assuming you're getting the file in order you can just use standard AES-CBC to encrypt all the blocks of the file and save it to disk. The window of time while the file isn't encrypted isn't terribly ...


5

These WORM (write once read many) devices are by definition inconvenient and that's why there are very few of them and rather expensive. The expensive part is because it has to have hardware support. You could try doing it on the same system with read-only rights for certain users and harden it with the immutable attribute. Even root cannot delete those ...


5

Can this be achieved with Keystore? I don't think that fits your use case. Keystore is designed to store cryptographic keys that will be used for encryption, decryption and signing. The idea is that these keys will be out of reach of the application using them, so basically, if you need something signed or encrypted, you call a system function that has ...


5

Cookies set by scripts are always associated with the webpage's domain, not the domain that the script came from. (If this weren't the case, then it would often be easy to include a script from a remote domain and a second script which redefined global functions to trick the first script into reading or setting arbitrary cookies on the remote domain.) ...


5

Let's begin with the easy part: Option #2 is a non-options. It comes with no CSRF-protection, so it is inherently vulnerable. Actually, option #3 is pretty much option #2 with CSRF-protection on top. So you are right to focus your question on the choice between #1 and #3. Are there any other benefits of Option 3 over Option 1? Not really. And the I'm not ...


5

The main problems are: The username and the password are sent again on every request, making it easier to steal the actual credentials instead of hijacking the session. A compromised session can easily be revoked by removing the access token, but a compromised login requires locking the account and changing the password. Cookies could be stolen... in man-...


4

There is always an operating system, albeit not necessarily a complex one. The BIOS is an OS in the strict sense of the term: it provides access to hardware through an hardware-independent API. The boot code for an OS (or some malware that pretends to be that boot code) uses the BIOS-provided API to read (and possibly write) bytes from the hard disk. ...


4

What you want is something that ensures integrity of your data. The most common solution for this is to use an HMAC, that is a keyed digest. NodeJS has an API that calculates HMACs. Compared to a "salted" hash, where you would keep the salt private, HMACs are designed to be secure even against some additional attacks, such as length extension attacks. As ...


4

The goal here is to keep the token secret, even if an attacker exploits an XSS vulnerability - sort or like emulating the HTTP-only flag for cookies, in other words. I guess the closure would be a function that calls the API for you, using the token for authentication, and then return the result of the API call. In that way, you never have to touch the token....


3

Following the advices from the auth0 blog you can counter security concerns by keeping a low token expiration value and more importantly you can encrypt the token. An alternative approach would be the use of JSON Web Tokens in association with OAuth2.


3

Both cookies and localstorage are accessed via JavaScript APIs. When the attacker can inject JavaScript into the target's html document, they can read and write them equally. A comment mentions http-only cookies. But those can not be accessed by client-sided JavaScript applications at all, so they are not competing with localstorage in most scenarios. But ...


3

Not using a VM will leave you totally dependent on the static analysis programs and any other program (hex editor, text editors and so on) you use. This is dangerous. In my opinion, too dangerous. Like Matthew said, any bug in, say notepad++, will put your archiving machine at risk of being attacked when all you think you are doing is analyzing the file. ...


3

Making brute-force attack the only possible option is a desired feature of a security system. This "only" would mean there are no weaknesses in the algorithm or implementation and the system could be broken only by trying all combinations of possible passwords. On top of making sure brute-force attack is the only possibly, it should also be made difficult ...


3

I assume you mean a server-side identifier, like PHPSESSID or ASPSESSIONID. Client accessibility comes to mind. With cookies, they can be marked as HttpOnly, thus making them unreadable from JavaScript. This mitigates an attacker that exploits XSS from stealing your session cookie because a complying browser will refuse to give the cookie to the malicious ...


3

A cookie marked httpOnly, as the name implies, cannot be accessed from javascript. So a 'conventional' web application using cookies is not vulnerable to naive XSS attacks if that flag is set (assuming no browser bugs expose it of course.) Notably such a solution is vulnerable to CSRF, so more work is required to mitigate that. In SPA frameworks you ...


3

Terrible idea. Don't store the password in clear text between pages, not on the client and not on the server. Redesign your page flow (for instance by only entering the user name on the first login page, then branch to the registration page if it does not exist), or if you can't, let them re-enter the password.


2

Yes it is of course. The simplest example is the user who just submits the request as http://..., either unconsciously or by will. The (potentially malicious) web server could do that too, by just sending a 30x redirection or a page with all further hyperlinks pointing to http:// instead of https:// Example for the latter one: connect to https://www....


2

Actually Phonegap apps are not really "all native". Only system functionalities (like file access, camera access, etc.) are translated to their Java counter-parts. It still uses a webview and a lot of javascript to implement the application business logic. So, answering your question, the local storage issue is still a valid concern as it is a feature of ...


2

First thought is that it does seem to be quite a lot of tokens and it does beg the question if it's indeed a requirement for the authorization server to issue so many specific tokens or if less tokens with more broader applicability could suffice. However, focusing on your question... Besides the sessionStorage there is also localStorage which would tackle ...


2

I'm not 100% into security. I read something else out of it. The problem with "sensitive token information" is the same problem, be it a cookie or localStorage. But you can save far more data into local storage, which might bring up the idea, that it is a good idea to store all banking information, all transfers, etc. (please insert other risky information ...


2

On PC's the browsers local storage and cookie storage is not specifically protected. This means that any process running with the same or higher privileges as the browser will be able to read and manipulate this storage. Thus, if you run the game as a different and low privilege user it will only be able to access the browser storage if it manages to elevate ...


2

You should avoid consider storing sensitive data at all. Conceptually, if a system is compromised, it doesn't matter where you store the data; any code that can examine's the browser's memory doesn't need to directly access localStorage or an indexedDB, since it could be read straight from memory. So, store only the data you need, but keep in mind that a ...


Only top voted, non community-wiki answers of a minimum length are eligible