Obfuscated encryption fails again… No Shit, Sherlock!

This is obfuscation, rather than encryption, for all purposes.

Major hardware vendors are involved, and «the issue is worse on Windows». No surprises, then… Glad I don’t use that poor excuse for an operating system… 🙂

It seems a few popular devices with hardware controlled self encryption aren’t really doing it good by having master passwords (truly a #WTF) and faulty standards implementations.

«SSDs from Micron (Crucial) and Samsung are affected. These are SSDs that support hardware-level encryption via a local built-in chip, separate from the main CPU. Some of these devices have a factory-set master password that bypasses the user-set password, while other SSDs store the encryption key on the hard drive, from where it can be retrieved. The issue is worse on Windows, where BitLocker defers software-level encryption to hardware encryption-capable SSDs, meaning user data is vulnerable to attacks without the user’s knowledge»

There’s a paper with all the gory details for the hard core guys  and a report on ZDNet for the rest.

I love learning new stuff

Really! Learning new stuff is always good to improve yourself, even when it’s something so boring as accounting (well, this one I need to help myself believe it).

This is definitely not news for many people, but I always wondered how failban was blocking an ip.ad.dre.ss when I couldn’t find any of the banned IPs with iptables-save | grep ip.ad.dre.ss

I always left it for another time and boy did it pass long and quickly, with other things more important.

But no more! This past weekend I finally learned how fail2ban manages IP block lists with Firewalld: it uses ipset and then creates iptables multiport matches on that defined ipset!

Boy, was I happy… May come in useful in the future, and in the past it was definitely very useful at times, rather than other workarounds.

Still… nice. I must thrive to make time to learn new stuff at least every weekend.