Tag Info

Hot answers tagged

8

Actually, this has nothing to do with moving CryptoCat to a browser plugin/extension. It's not even related to SSL at all. Having that in mind, Stephen's answer is somewhat misleading. I'll attempt to address that. CryptoCat is still JavaScript & HTML. Give me your full attention, assume that SSL is doing its job and you're 100% sure that you're ...


7

HTTPS is still an absolute requirement, and Matasano's main point is that JavaScript can never replace HTTPS. A MITM attack could deliver a custom JavaScript payload that could read any secrets in localstorage, and an XSS payload could also compromise this data. Matasano is wrong in regards to random number generators in JavaScript. Most browsers provide ...


5

No, I don't know any website that is doing this. Simply, because it's a silly idea. The DOM is in the memory, and when you access it you're accessing objects stored in the memory. If a website wants to do this, it would simply store the cookie in a JavaScript variable. var Cookie = 'COOKIE_VALUE'; But there are much much better ways of creating sticky ...


3

In principle, values stored in sessionStorage are restricted to the same scheme + hostname + unique port, and if the browser has a clean exit these values should be deleted at the end of the session. However, according to this post it can survive a browser restart if the user chooses to "restore the session" after a crash (which means its values also exist ...


2

Seems to me to be a reasonably secure approach in lieu of having user accounts and session management. HTTPS is a must but I'd also look at the following points to address your specific issues. In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is. Make sure the generated string is ...


2

I suggest another approach: Instead of submitting the form to the server, use an XMLHttpRequest to create the account. If server side validation fails, the form and all its content is still available. If it was successful, redirect to the target page. This requires that JavaScript is enabled, but you still can fall back to normal form submission. Access to ...


2

You will be having hard time deciding on which of the two stored values to use as the user's intended password (the one in the local storage, or the one in the input field), if none of them are empty but for some reason differ. This can potentially provide for a social engineering attack vector, where the attacker prepares a trap by opening the registration ...


1

You are right encryption is mandatory for all WebRTC communications. All the communications are encrypted using Datagram Transport layer Security (DTLS), which is a derivative of SSL. DTLS is build in to all browsers that support WebRTC. In short the the keys for the peer-to-peer SSL connection are generated by the peers and exchanged over the signalling ...


1

Essentially, the only way to achieve this sort of thing is to send Javascript and HTML to the browser. But the inherent problem is that the security of the entire system is entirely dependent upon serving HTML and Javascript to the browser. And this boils down to SSL and the Certificate Authority system. So at best, the security of any purely HTML and ...



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