How many PBKDF2 rounds does it take to change an encrypted lightbulb?
Welcome to the inaugural Illuminated Security newsletter. I intend to publish this newsletter once or twice a month. Each email will have an in-depth discussion of a single topic in application security or applied cryptography, together with links to stories and articles from the wider community.
Introducing Illuminated Security
I guess as this is the first newsletter, I should say a little about who we are! Illuminated Security is a startup developing online and in-person training courses around application security and modern applied cryptography. We hope to launch our first courses in the next few months. In the meantime, please subscribe to the newsletter to keep informed with our plans.
Using passwords for encryption
This month there has been a lot of chatter about the LastPass breach. Some of the best discussion has been on Mastodon, as everyone in InfoSec flees Twitter to the infosec.exchange server. Jeremy Gosney has written about the breach from a password cracker's perspective, with a follow-up about alternatives to LastPass.
One aspect of the design of LastPass that has drawn some criticism is that they use a key derived from your password using PBKDF2 to encrypt your vault. Other designs from 1Password, Apple, and others, combine your password with a high-entropy secret key. PBKDF2 repeatedly applies a cryptographic hash function to a password to derive an encryption key. The idea is that by applying lots of iterations (rounds) of the hash function, you can make it expensive for an attacker to brute-force your password.
A lot has been written over the years about password hashing, and exactly how many iterations should be used to achieve decent security. But almost all of this discussion is in the context of online authentication—logging into a website using a password. In this case, the KDF only has to slow down the process long enough for you to discover a breach and change your password (or notify your users). However, if you are encrypting secrets with a password, as in the LastPass case, then there is no chance to change your password: once the attacker has stolen the encrypted data, they can take as long as they want to brute-force your password. So how many PBKDF2 iterations would you need to use to ensure your secrets are safe in this scenario? This is the topic of today's newsletter, which I have covered in detail on my blog: On PBKDF2 iterations. (Discussion: Mastodon, Reddit, Hacker News).
The tl;dr is:
there is no sane parameters for password hashing that provide anything like the security levels expected in modern cryptography.
If you want to ensure long-term security, there is no substitute for using high-entropy secrets.
Other articles, blogs, podcasts that have caught my attention recently:
Before Christmas, Emily Stark of the Google Chrome team, wrote a fantastic post about the death of the line of death. The "line of death" is a boundary between trusted and untrusted content in web browsers, and Emily shows how this boundary has eroded over the years and what might replace it.
Kenny Paterson's team at ETH Zurich have been breaking stuff again. This time finding several vulnerabilities in the Threema secure messaging app, despite them using NaCl for cryptography. As the researchers state "Using modern, secure libraries for cryptographic primitives does not, on its own, lead to a secure protocol design". The paper is well worth a read, with lots of lessons on modern secure protocol design.
Soatok has written the definitive article on password-based cryptography: "Password-Based Cryptography is a mess".
The ever-wonderful Security. Cryptography. Whatever. podcast has the definitive take on the latest attempt to destroye the RSA cryptosystem.
That's it for this month. If you spot anything that you think I should include in future newsletters, feel free to email me: Neil Madden.