Since our inception, we've typically published retrospective blog posts every year:
A recurring theme of these posts has been, "We have an ambitious plan to make the Internet more secure."
At the end of 2015 looking towards 2016, we wanted to emphasize "secure-by-default" as the best attitude towards security.
Our goal for 2017 was to get libsodium into the PHP core (which we did! The vote passed 37 to 0) and write a pure-PHP polyfill library we call sodium_compat.
Our goal in 2018 was to kickstart an ecosystem-wide clean-up effort to address the discoverability problem: It's much easier for new PHP developers to discover bad security advice than good security advice. We wanted to flip the script on this problem and make new developers learn tools and techniques that are, at a base, far more conducive to developing secure applications.
This was somehow even more ambitious than our 2017 goal, and unsurprisingly, we didn't have the same measure of success this time around. But the campaign is still young, and may take several years to play out in full, and we believe a recent announcement from another organization shines a light of hope on our efforts. More on that in a minute.
Today, we answer some reader questions about secure credential management, the benefits of ChaCha and BLAKE2 over AES and SHA2, and fault attacks on EdDSA.
Astute readers have noticed that our blog posts have decreased in frequency this year. We put a heavy emphasis on quality, not so much on quantity.
At the same time, we field a lot of questions on social media, where our answers (and, sometimes, the questions themselves) are difficult to locate, especially when people close or lock their accounts.
With both of these thoughts in mind, I asked my Twitter followers if they'd be interested in a Q&A-style blog series. I expected maybe a 55:45 split on yes/no responses, but the final tally was overwhelmingly "Yes".
So with that in mind, I'd like to introduce the pilot for our new series, Slice of PIE.
Earlier this year, the World Wide Web Consortium (W3C) and FIDO Alliance shared their latest drafts for a standard Web Authentication API called WebAuthn.
Our security team took an interest to this proposal since WebAuthn would be used in conjunction hardware two-factor authentication devices. Hardware 2FA has proven to be far more resilient against phishing attacks than HOTP or TOTP (meanwhile, SMS-based 2FA is essentially security theater; avoid like the plague).
Despite the importance of WebAuthn to web security for the years to come, our analysis of the standard reveals a lot of concerns that almost any cryptographer should have been able to identify and remedy earlier in the design phase.
Regardless of whether this was a failure of the W3C and/or FIDO Alliance to enlist the aid of cryptography engineers, or of the cryptography community to be more proactive in preventing the deployment of error-prone cryptographic designs, there is only one path forward; and that is to fix the design of WebAuthn before it's set in stone.
Asymmetric cryptography (also known as public-key cryptography) is widely misunderstood.
Most non-cryptographers don't understand asymmetric cryptography at all due to the lack of a relatable, real world analogy they can reference.
Conversely, most cryptographers don't seem to understand how and why developers use asymmetric cryptography in their own software.
I believe solving both problems (first, assisting developers understand what asymmetric cryptography is and how it works; but also, ensuring cryptographers understand the business needs that lead to the inclusion of asymmetric cryptography in software) will lead to all-around better cryptography designs and non-catastrophic asymmetric cryptography deployments.
Will tomorrow bring costly and embarrassing data breaches? Or will it bring growth, success, and peace of mind?
Our team of technology consultants have extensive knowledge and experience with application security and web/application development.
Want the latest from Paragon Initiative Enterprises delivered straight to your inbox? We have two newsletters to choose from.
The first mails quarterly and often showcases our behind-the-scenes projects.
The other is unscheduled and gives you a direct feed into the findings of our open source security research initiatives.