All that's required is to create a malicious software package under a hallucinated package name and then upload the bad package to a package registry or index like PyPI or npm for distribution. Thereafter, when an AI code assistant re-hallucinates the co-opted name, the process of installing dependencies and executing the code will run the malware.

Aboukhadijeh explained that _Iain "automated the creation of thousands of typo-squatted packages (many targeting crypto libraries) and even used ChatGPT to generate realistic-sounding variants of real package names at scale. He shared video tutorials walking others through the process, from publishing the packages to executing payloads on infected machines via a GUI. It’s a clear example of how attackers are weaponizing AI to accelerate software supply chain attacks."

Not in France.

3.5 millions fines after a ransomware attack because no security measure was set.

Fin de l’article ??? Naaaaan ! Attendez une minute, bande d’impatients ! Car quand on regarde sous le capot, on se rend compte que Google joue “un peu” avec les mots. Ils appellent ça “end-to-end encryption” (E2EE), mais les puristes de la sécurité sont en train d’hurler au scandale (et pas “d’hurler aux sandales”, c’est pas encore les vacances). En réalité, ce qu’a mis en place Google s’appelle du “client-side encryption” (CSE). La différence n’est pas juste sémantique, elle est fondamentale !

Dans un vrai système E2EE comme Signal ou WhatsApp, les clés de chiffrement sont générées et restent uniquement sur les appareils des utilisateurs finaux. Personne d’autre, pas même le fournisseur du service, ne peut déchiffrer les messages. C’est le Saint Graal de la sécurité des communications et c’est bien pour ça que les Etats veulent des backdoor dans tous ces services !

Mais avec le CSE de Google, les clés sont générées ET stockées dans un service cloud de gestion des clés. Les administrateurs peuvent donc y accéder, révoquer des accès, surveiller ce que les utilisateurs chiffrent. Donc c’est un genre de un coffre-fort ultra-sécurisé protégeant vos données les plus sensibles, mais où le mec qui l’a installé a gardé un double de la clé “au cas où”, et pourrait même regarder ce que vous y stockez s’il s’emmerde.

Modern cryptography

Hashing: BLAKE3, Keccak-based functions (SHA-3, SHAKE256) or BLAKE2b.

Encryption: XChaCha20-Poly1305, ChaCah20-BLAKE3, or, I would like to see keccak-based AEAD constructions.

Key Exchange: X25519, X448

Digital Signatures: Ed25519, Ed448

Password Hashing / Key Derivation: Argon2id

Conceptually it's very simple: when you signup for a service, you generate a private and public keypair. The private key is stored in your passkey manager [...], and the public key is stored in the database of the service. Then, during a login, the server sends an randomly-generated challenge, your device sign it wit the private key, and the server verify that the signature of the challenge matches the public key.

An alternative to passwords.

A demo for passkeys

Based on Cloudflare's observed traffic between September - November 2024, 41% of successful logins across websites protected by Cloudflare involve compromised passwords.

How do they know it exactly?

what is your mother's maiden name?

Pick random words or another password and store it in the password manager. It's easier that way.

Due to being random and unique per site, it's far more secure.

Encoding the malware as an array of UUIDs

The scroll-animated graphic is well made. It goes through the different topic step by step.

Loading a ressource can deanonymise a user:

1. Cloudflare CDN shares the nearest airport in its HTTP header Cf-Ray
2. A favicon cache works: "Since everytime you load their site, your browser automatically downloads this favicon, this means a user from each one of this locations has visited the Namecheap.com site within the 5 minutes with the last visit from Tokyo, Japan.". So if you lead a specific content created only to target one user, you can know from which data center the content is loaded (and its nearest airport).
3. As Signal uses Cloudflare caching for the attachments, the same attack can be exploited.

With an innocent-looking attachment, an attacker can deanonymize users and find their location within an approximate radius (tens of miles, depending of the datacenters).

It works only if the user clicks to download the attachment in this case.

4. Push notification of Signal with an image can trigger the cache... So a 0-click exploit can exist.

If the target has push notifications enabled (which it is by default), they don't even have to open the Signal conversation for their device to download the attachment. [...]
An attacker can run this deanonymization attack any time and grab a user's current location without a single interaction.

A similar exploit can be used on Discord with custom emojis: the custom emoji is a custom content downloaded by one user.

Conclusion:

his attack can be used to track Signal accounts, correlate identities, find employees meeting with journalists and much more.
Any app using a CDN for content delivery and caching can still be vulnerable if the proper precautions aren’t taken.

Useful to get alerted when one website copies another or someone is copying your achitecture.

I don't understand: 2FA in a password manager makes it vulmeran

For maximum security, you can store your 2FA token elsewhere, like a YubiKey (see Yubico Authenticator) or Google Authenticator, and keep the recovery codes safe somewhere outside your computer, but for general purpose use, storing your 2FA in your password manager is an acceptable solution due to the convenience benefits it provides.

I still think it is better to split passwords and 2FA on two systems for security purposes.