0

My friend has an idea about protecting the stored cookies in browser with adding an encryption on them using library such as Stanford Javascript Crypto Library.

Meanwhile i believe such actions are not possible because, javascript has no access to file system.

The question is:

what would be the functionality the said library?

What does it encrypt? I believe the encryption of it would be limited to variables of js application and not files on the host

Sal-laS
  • 11,016
  • 25
  • 99
  • 169
  • 1
    why would encryption require access to the file system – Jaromanda X May 24 '17 at 09:50
  • besides, encryption on the browser seems irrelevant, since the user can see the encryption code ... in the browser – Jaromanda X May 24 '17 at 09:51
  • @JaromandaX what do you mean 'see the encryption code'? If the crypto algorithm is strong enough and the secret is hidden from the client then encryption will be secure. – Aron May 24 '17 at 09:53
  • if i can encrypt the files using js on file system, then i would run an attack to perform the encryption. so, i think, the encryption should be locked for the same reason that it blocks delete file – Sal-laS May 24 '17 at 09:53
  • @Aron You cannot hide the secret from the client when you are performing the computation on the client? – Bergi May 24 '17 at 09:54
  • Again, cookies are separate from the file system. Cookie access is part of the browser API and is totally separate from the file system. – Aron May 24 '17 at 09:55
  • @Bergi good point. – Aron May 24 '17 at 09:55
  • @Bergi the purpose of encryption is not hiding from the user, but hiding from unauthorized attackers – Sal-laS May 24 '17 at 09:55
  • In general, you can encrypt *all* data that can be represented in binary – Bergi May 24 '17 at 09:56
  • 3
    @Salman Which attackers exactly? You don't seem to have a clear idea of the threat model. – Bergi May 24 '17 at 09:56
  • Client-side symmetric encryption in Javascript has very few benefits due to the fact that the encryption key is easily recovered. If the same key is used for all clients, then encryption is pointless. – Luke Joshua Park May 24 '17 at 09:58
  • 2
    @Salman If you are hiding information from attackers and not the end user then HTTPS is more than enough. – Luke Joshua Park May 24 '17 at 09:59
  • Protecting the cookies ? Protecting from what ? Encrypting the value then asking the browser to store the encrypted value can definitely be done, but the point of this is unclear at best. – Nicolas Marshall Jul 10 '17 at 08:24

2 Answers2

1

Cookies are in fact accessible via JavaScript, just like the DOM is.

You could encrypt them by running the value you want to store through the encryption algorithm.

Depending on what you want to store and how the encryption/decryption mechanism works this may or may not be a good idea.

Aron
  • 8,696
  • 6
  • 33
  • 59
1

You're asking

What kind of data could be encrypted using javascript?

and Bergi answered that in the comments:

In general, you can encrypt all data that can be represented in binary

That's true, but this is not what you're actually trying to ask. I believe you're looking for scenarios where crypto libraries are useful in the browser. But more on that a little further down.

I believe the encryption of it would be limited to variables of js application and not files on the host

Yes and no. Anything that can be accessed by JavaScript, can be encrypted. Whether this encryption adds any security is a whole other issue. Values that are accessible through variables in JavaScript code can be encrypted. The same goes to user input which includes files that the user explicitly opened in order to upload in a file dialog (example).
Additionally, your JavaScript code has access to the whole file system in Chrome if you really want it.

Here are some scenarios where using Cryptography in JavaScript could make sense, but not all of them are recommended (not exhaustive, but common):

  • File storage (i.e. Mega) where the symmetric encryption key is never sent to the server but kept on the client or is directly entered by the user. Its security depends on your trust that the service provider doesn't change their own JavaScript and log the key that was used for encryption.

  • Password-manager (i.e. clipperz) is similar to file storage, but its code is injected to other sites and it must be resilient to not blurt out all its secrets. It can use many different cryptographic primitives.

  • Poor-man's HTTPS (i.e. too many Stack Overflow questions) where the server has its RSA private key and sends the RSA public key over HTTP (sic!) to the browser. The browser can encrypt any data and send it back to the server (maybe also establishing a symmetric key in the process). The server can decrypt the message with its private key and respond. This is sort-of secure as long as there is no man-in-the-middle attacker that simply injects its own JavaScript that copies any browser data to the attacker's server. SJCL implements ElGamal encryption instead of RSA for this use case.

  • Hashing data before uploading in order to check for transmission errors or achieve deduplication (no need to upload file, because somebody else already did so). Hashing is technically in the realm of cryptography and many libraries to that.

  • Online calculators (i.e. my authenticated encryption tests) where valid and easy to use implementations or algorithms can be used directly when implementing the same algorithms in another language. The data is never sent to the server and is encrypted purely in the browser. My "calculator" can be used to test ones own implementation, because it is verified by various test vectors. Others are there to help friends pass hidden messages without proper e-mail encryption.

These should not be done with browser-based crypto:

  • If you're using only symmetric encryption over HTTP and the exact same key is present at the server and the client, then you have a problem, because the key must be sent in some way for the client to the server or back. If you send the encryption key from the server to the client or the other way around you need to encrypt your symmetric encryption key. The easiest way to do this would be to use TLS. If you use TLS, then the data as well as key are encrypted, so you don't need to encrypt it yourself. This doesn't provide any security, just a little bit of obfuscation. Any passive attacker (observer) can read your messages. You should read: Javascript Cryptography Considered Harmful

  • Hashing a password for log in is a bad practice. The general consensus is that you need to hash a password many times (PBKDF2, bcrypt, scrypt, Argon2) in order to check whether a user has sent the correct username and password. Some think that if we hash on the client, the password is not sent in the clear over the network and everything is secure. The problem is that if they think that, they are not using HTTPS (which they need). At the same time, the hashed password is their new password. If the server doesn't implement a constant-time comparison, it is trivial to use a timing side-channel attack to log in as any person which you know the username of.

  • JWT for sessions: Part 1 and part 2

Artjom B.
  • 61,146
  • 24
  • 125
  • 222