NOTE: Updated March 2022
In this blog we look at encryption and why it’s used, consider why double encrypting data is classed as taboo in development and explain why Beacon uses double encryption in specific systems.
Why is encryption used?
Encryption’s primary purpose is to protect against brute force attacks or Man in the Middle (MITM) attacks. It is composed of a cypher (the encryption method), ciphertext (the message/data) and a key (the password). With a wide range of free tools available, even novice hackers can attempt to hack passwords using brute force (dictionary or list-based attacks until a match is found).
What is the most common encryption used for?
You will have seen the little padlock or a green bar that appears on some websites in the address bar. This is the most common type of encryption you will find. It essentially means the website is using HTTPS and the browser is using a connection which is secured by using an SSL or TLS certificate.
Why do so many developers dislike double encryption?
It’s easy to find discussions where, whenever a question about encryption comes up related to a web request, many people will start a debate stating HTTPS alone is enough.
There are a few reasons they give for it, but two come up most frequently.
The first is that there was a security flaw discovered where two encryption methods could possibly cause a conflict with each other and therefore make it easier to break the encryption as a whole. Wikipedia has a good article about one possible attack vector (Collision Attack). I won’t go into details in this blog but it’s one of the reasons developers were put off using double encryption even though those methods would not be used in the present time.
The second reason is that it does not add much more protection – as Diffie and Hellman Discovered in 1977 – to the data as a whole. This is because it doesn’t double the security, as one would seemingly think it does, but in fact only adds about one bit of extra security when fully encrypted.
Given this, when should you double encrypt?
There are two common reasons to double encrypt. Firstly, you want your servers to save the information in a way so that they are not able to perform the decryption.
For example, a user-provided password-encryption where the password is actually a passkey that gets used to create the key of the encryption and the server never saves or may never know the password.
The second I will go into more detail about, as this is one which affects us here at Beacon.
Browsers are becoming more secure, as users of the world wide web move towards getting rid of non-encrypted websites and promote the switch to HTTPS as a minimum. However, browsers these days are also user-friendly and most are built on top of Google’s version of Web Kit which supports client-side extensions like AdBlockers, Amazon Assistant and, one I frequently use – Grammarly.
But with these developer systems, it’s possible to have an extension run code in a tab before the main content of a page is downloaded and secured by the browser, therefore making it perfectly possible for an extension to use the browser’s own technology against it.
A Theoretical Example
Assume I have got the code of the ad block extension, something which is easily doable as the code is stored on my machine so my browser can run it. I could then copy that, make my own version and then release it – creating a new ad block extension, yay!
But, I could also modify it to run a Javascript file by telling the browser to run it at “document_start” – i.e. before the Javascript of the webpage has had time to run and secure the environment.
This means I could get the script to run something like in the code below.
(() => {
debugger;
let openParams = {};
class XHR extends XMLHttpRequest{
openParams;
open(m, u, a, us, p){
openParams = {m, u, a, us, p};
super.open(m,u,a,us,p);
}
send(t){
const d = JSON.stringify(openParams);
console.log(`you sent ${t} via ajax opened to ${d}`);
super.send(t);
}
toString(){
return super.toString();
}
}
XHR.toString = () => {
return "function XMLHttpRequest() { [native code] }"
}
console.log(XMLHttpRequest);
console.log(new XHR);
XMLHttpRequest = XHR;
console.log(XMLHttpRequest);
alert("AJAX has been hacked if you see this find the extension causing this and remove it.")
})();
This allows me to capture everything posted via AJAX to a server, so if any secure information is sent, I would have a copy of it I could then send on to my own server to record and use at a later date.
Because the code is running in and modifying Javascript, any “on-page Javascript” is now run AFTER my code and is calling my code instead of the browser’s native code. My code then executes the browser native code to not break the functionality.
Due to AJAX or Javascript not being responsible for the HTTPS encryption, this is handled by the browsers own underlying technology, it’s also possible to capture the response sent from the server as it passes back to the Javascript implemented handler and record that as well.
NOTE: The code given above will not work correctly in real life. It requires developer intervention that prevents it being used to exploit the browser in the way I have explained, this is deliberate.
Here is an image of the example running and the injection working.
As you can see, there is a console log of all the data sent and the parameters outlining where the data was sent to.
While this is a minimalist example that wouldn’t work in a real environment because of the debugger statements, it does still demonstrate a theoretical circumnavigation of the protection HTTPS Encryption provides which is supposed to offer protection against MITM Attacks. (This is a MITM attack because the extension has become a middleman to the data transmission.)
So, To Conclude
The moral of the story is that there is a use case for double encryption but it’s not there to make the total encryptions doubly secure, it’s to protect from client-side MITM attacks. Or from attacks on a server breaking the encrypted data it has access to.
The Beacon Platform is a React App so all our requests use an XMLHttpRequest whenever we’re sending sensitive data from the browser – such as email addresses or password – we use Sodium encryption in the Javascript first to prevent an extension extracting the secure information from the requests to our servers.
You should also never use the same encryption algorithm more than once.
We hope you found this article interesting. Let us know on our social media if you’ve got anything to add!