Showing items from Cybersecurity

post-thumb

Migration towards Quantum-Safe payments

Introduction

Today’s payment systems are heavily dependent on traditional cryptographic security protocols such as RSA 2048 (asymmetric) and AES 256 (symmetric) to secure data and communications. The NIST also recommends [1] RSA 2048 key size is the most used in the industry such as EMV 3DS specification recommends such key size [2] or above. The usefulness of the asymmetric cryptographic primitives RSA, Elliptic curve based, and symmetric cryptographic primitive AES are huge in payments, refer to our previous blog post to find in detail, you can find a description of where these RSA, Eliptic curve or AES cryptographic primitives are used for payments and how the asymmetric ones (RSA, EC) are absolutely threatened by quantum computers. And even if quantum computing does not pose a fatal threat to symmetric cryptography such as AES, you need to double the key length to guarantee the same level of security against a quantum computer attack.

Read more
post-thumb

Help! Quantum Computers are threatening our payments!

Introduction

Modern cryptography has been used to enable secure communications between individuals or servers, even if these entities do not share any pre-established secret. The cryptographic primitives allow kickstarting a secure channel primarily to deliver two main functionalities: protected channel establishment (known as key establishment) and authentication of digital information/parties (by the use of digital signatures). Once the channel is established, it can use other cryptographic primitives to secure communications over the Internet, provide the root of trust for secure transactions in the digital economy, and keep data private by encrypting it.

Read more
post-thumb

Invisible code and XSS attacks

Trojan: Attacks from the inside

XSS attacks were quite common at the time of the early web. They were used to steal cookies, to redirect users to malicious websites, to inject malicious code in the page, etc. Websites were more vulnerable to XSS at that time because they used a lot server-side templating with technologies like PHP or JSP, with very few built-in protections for injecting JavaScript code into HTML responses. Today, we are much more careful about escaping user inputs and evaluating HTML dynamically. We use frameworks like React or Vue.js to build our web applications, which are based on declarative templating that escape all HTML by default and encourage sending serialized data instead of HTML on the wire. Dynamic code evaluation is considered a bad practice and injection patterns are catched by code analysis tools like ESLint or SonarQube. XSS attacks have therefore to find more creative ways to inject malicious code into the page. If they can’t inject from the outside, they will try to inject from the inside, targeting the code of the application itself. They can do that directly through project dependencies or pull requests to open source projects, or indirectly through StackOverflow answers, blog posts, AI chatbots, etc.

Read more