The recent release of diplomatic cables by WikiLeaks has caused many to stop and think – which is always a good thing in my opinion. Of the many comments I’ve seen on this subject, one by Jeff Atwood seems to be the most relevant:
Be it for a personal vendetta, political reasons, or perhaps just the love of chaos; there is always somebody that would love to take your secrets & thoughtless words and expose them to the world. Even with the best security systems that the US Government could build, one person that wanted it all exposed was able to leak hundreds of thousands of documents before exposing himself and ending his crusade.
We should all be taking at least some precautions to protect our private communications, ensuring we use SSL wherever possible, avoiding unencrypted wireless networks, encrypting sensitive data and the like. By making a few smart decisions our secrets are a little safer, but there’s always the risk that there will be an insider ready and waiting. Anytime there is interesting communication, there will be people who want to see it exposed.
In my current position, I tend to see a lot of dirty laundry go through my inbox – nothing illegal, but some things that could certainly be embarrassing. At times I’m amazed that people would type some of the things that they do, both our clients and internally. If they had been a little more careful about what they said, nobody would ever care; but as it stands, if publicly released they could lead to a real black-eye on somebody’s reputation.
To minimize exposure to these risks, words should be carefully chosen and the impact of public disclosure always considered.
Obviously though, there are times that the subject is sensitive and that is simply unavoidable. All one can do is take all the reasonable precautions and carefully consider the impact of their words, should they be exposed to the rest of the world.
As Shapchat has increased in popularity, I’ve been asked several times to revisit my Snapchat API & Security post, to address the changes that they made in response to my complaints. So, here is it – sorta.
I started making detailed notes and looking at the changes they made – but yesterday @tlack made that mostly irrelevant with his release of Snaphax, a PHP library to interact with the undocumented Shapchat API.
A few days ago, 1Password (my employer) released the first preview of the new application for macOS. The response has been rather dramatic. The release was followed by an excellent blog post by Michael Fey explaining the story of how we got here, and some of the decisions that were made in the process.
I’d like to now to a few minutes to answer some questions, provide some insight, and share my thoughts on this release.
The Nemucod ransomware has been around, in various incarnations, for some time. Recently a new variant started spreading via email claiming to be from UPS. This new version changed how files are encrypted, clearly in an attempt to fix its prior issue of being able to decrypt files without paying the ransom, and as this is a new version, no decryptor was available1. My friends at Savage Security contacted me to help save the data of one of their clients; I immediately began studying the cryptography related portions of the software, while the Savage Security team was busy looking at other portions.
When you are looking for TLS (SSL) certificates, there are three different types available, and vary widely by price and level of effort required to acquire them. Which one you choose impacts how your certificate is treated by browsers; the question for today is, are EV certificates worth the money? To answer this, we need to understand what the differences are just what you are getting for your money.
The Three Options For many, the choice of certificate type has more to do with price than type – and for that matter, not that many people even understand that there are real differences in the types of certificates that a certificate authority (CA) can issue.
A couple hours ago, Mike Santillana posted to oss-security about a rather interesting find in Ruby’s OpenSSL library; in this case, the flaw is subtle – so much so that it’s unlikely that anyone would notice it, and it’s a matter of a seemingly insignificant choice that determines if your code is affected. When performing AES-GCM encryption, if you set the key first, then the IV, and you are fine – set the IV first, you’re in trouble.
