222 private links
Utiliser des portes dérobées est à double tranchant: un attaquant peut aussi les exploiter. Pour un de ces raisons, les experts en cybersécurité déconseille les portes dérobées.
Instead of hash functions to store password, use Password-Based Key Derivation Functions (PBKDF) such as Argon2id.
bcrypt should be avoided due to its huge footgun: it truncates inputs longer than 72 characters. Okta AD/LDAP was vulnerable because of it.
Checksum functions such as CRC32 and xxh3 are optimized for pure speed and don't provide any security guarantees about their output, and it's easy to find collisions for a given checksum.
In 2024 based on I/O speed, a hash function with a throughput of 1 GB / s / core is considered fast enough for most use cases.
I skip the speed part because it is not relevant for me: 100MB/s or 1GB/s does not make much difference.
SHA3 and the BLAKE family which produced secures hash functions that are also misuse resistant.
A strength >= 128 bits is considered secure. The security agencies recommendation are a bit different. Hash length ranges from 256 (NIST) to 512 (ECRYPT-CSA).
SHA3 has many functions, SHA2 is vulnerable to length extension attacks (secret || message)
but BLAKE3 has none of these issues.
Post-Quantum security from Grover's algorithm divides by 2 the preimage and 2nd-preimage resistance. The BHT algorithm predicts however that a quantum computer can find a collision in operations instead of 2^n/2
So SHA2 for convenience or BLAKE for the rest. There is only C and Rust that have official support for BLAKE though.
The intention of this page is to collect and highlight malware written in the Rust programming language, so that malware reverse engineers have a collection of Rust samples to practice reversing on.
J'ouvre l'espace "dépôt de documents" sur le site de ma mutuelle, et je vois un Thumbs.db.
Purin encore un machin géré sous Windows. Non seulement géré sous Windows, mais accédé via cette saleté d'explorateur de fichiers Windows :facepalm:
J'imagine les employés qui viennent double-cliquer sur les fichiers déposés par les adhérents😬
Les probables problèmes de droits entre répertoires, les fausses manipulation (entre adhérents) trop vites arrivées quand on manipule de fichiers à la souris, etc
La fuite est encore incertaine, mais peut être réelle.
Adding a proof-of-work algorithm can work with this experience.
I guess that the main lesson was that these particular spammers, are really low-effort creatures. You raise the bar a little, and they stop being effective.
How to better use JWTs
Icedrive
pCloud
Icedrive
Seafile
Tresorit
Each company reacts differently.
Mais certains experts en sécurité ont exprimé récemment de fortes inquiétudes quant au fait que le ME [Management Engine des processeurs] pourrait cacher une porte dérobée, car il fonctionne indépendamment du système d’exploitation et a accès à la mémoire, au réseau et au matériel.
Korben revient sur l'historique de securité de Intel, avec plusieurs failles démontrées...
En plus des problèmes de sécurité, la CSAC critique la fiabilité des produits Intel et son attitude face aux plaintes des utilisateurs.
À suivre car la CSAC n'a encore publié aucune preuve, et qu'Intel n'a pas encore répondu.
The purpose of the attack appears to be for intelligence collection as the hackers might have had access to systems used by the U.S. federal government for court-authorized network wiretapping requests.
This is why putting a backdoor is risky
ICMP packets with "LOVE" in ASCII.
TCP packets with different window sizes.
This strange traffic mimics legitimate data streams, and while it's not known if it's malicious, its true purpose remains a mystery.
quick recap
- arc boosts can contain arbitrary javascript
- arc boosts are stored in firestore
- the arc browser gets which boosts to use via the creatorID field
- we can arbitrarily chage the creatorID field to any user id
thus, if we were to find a way to easily get someone elses user id, we would have a full attack chain
when someone referrs you to arc, or you referr someone to arc, you automatically get their user id in the user_referrals table, which means you could just ask someone for their arc invite code and they'd likely give it
Context:
To understand what’s happening here you need to remember that it’s a category error to treat LLMs as thinking entities.
They are statistical models that work with numbers – tokens – that represent language and the relationships between the words. It’s statistics about language wrapped up in an anthropomorphic simulation.
Attack:
The token stream (Strategic Text Sequence) itself – the numbers not the words – is an attack surface.
Reality of the threat:
This is going to get automated, weaponised, and industrialised. Tech companies have placed chatbots at the centre of our information ecosystems and butchered their products to push them front and centre. The incentives for bad actors to try to game them are enormous and they are capable of making incredibly sophisticated tools for their purposes.
Vu que les fuites de données ne sont pas vraiment évitables, est-ce que ces sociétés vont moins collecter des données?
(via https://sebsauvage.net/links/?Qgk2LA)
Constatant que le TLD .mobi (TLD qui est par ailleurs une mauvaise idée, mais c'est une autre histoire) avait changé son serveur whois, de whois.dotmobiregistry.net à whois.nic.mobi, et que le nom de domaine dotmobiregistry.net, non renouvelé, avait expiré et était donc libre, les chercheurs ont enregistré le nom dotmobiregistry.net, mis en place un serveur whois (je rappelle que le protocole est très simple et que n'importe quel·le étudiant·e peut programmer un serveur whois en un quart d'heure) et récolté d'innombrables requêtes provenant de clients whois qui n'avaient pas mis leur base à jour.
Les chercheurs ont ensuite analysé ces requêtes.
Afin d'éviter cette faille et "si on veut faire les choses proprement, on ne doit plus utiliser whois mais son successeur RDAP"
Un article détaillé de ArsTechnica est disponible à https://arstechnica.com/security/2024/09/rogue-whois-server-gives-researcher-superpowers-no-one-should-ever-have/