ENTRIES TAGGED "security"
Over time, crypto-currency networks such as bitcoin will get stronger
If a crook gets access to the credit card or wire transfer networks, it’s a disaster. That’s because, as I explained in my recent article about security models, these traditional financial networks achieve trust by excluding bad actors through access control. Effective access control requires exclusivity and strict vetting, only a small carefully vetted group of “trusted actors” are granted control.
Bitcoin and other crypto-currencies based on the blockchain invention are different. Trust is based on computation, not access control. On the bitcoin network you trust math so everyone can have access. That also means that there will be bad actors, arguably just as there are on access control networks, and nuisance attacks. Fortunately, these types of attacks cannot affect the distributed asset ledger, the blockchain, because to achieve the level of trust to write into the ledger you must apply enormous distributed computation. The root of trust is in the majority of computing power, not individual actors or any central authority.
This controversy impacts everyone (and here's what we can do about it)
As a cyber security author and CEO of a security consulting company, I was personally shocked by the RSA’s attitude about the alleged secret payments it received from the NSA as well as its willingness to weaken its BSAFE product; especially after the weakness became public in 2006. I was even more shocked by the lack of outrage shown by many security bloggers, analysts, and security company executives.
The speaker-in-protest count has reached 13 speakers who have canceled talks they were scheduled to give at the RSA Conference (RSAC) next week, first and most notably, Mikko Hypponen, who published this open letter. A few outraged others have also spoken out about their decision to cancel their talks, including Dave Kearns and, via Twitter, Adam Langley and Josh Thomas.
Check for bad effects instead of suspicious traffic
Being a part of the security industry for many years, we loved to watch all of the traffic coming and going from a network or even the servers. There was never enough data and as security folks we wanted to watch every inbound and outbound packet, because, well, it could be malicious. We’d copy all of the traffic when necessary, sift through it, and try to find events that could be from hackers. We’d even throw tons of costly hardware at the problem just to review traffic in real-time. All of this was done to achieve one goal: find attacks before they entered the network and did damage.
Specifically, we would place sensors at key choke points in the network or places where we could see a great deal of the traffic. The sensors could be placed in what was called detection mode, where a copy of the data would be sent to the sensor, or in prevention mode, where all of the traffic would pass through the device. Either way, the sensor would review each packet, collection of packets, or user sessions against a set of known bad “signatures” or just try to identify anomalous behavior. The theory was very similar to anti-virus technology, where known bad packet flows would be detected and propagated to all customers. The industry worked so well at this they generated tens of thousands of signatures.
Using bycrpt for safer password storage
As anyone whose used a web applications knows, the password is still the go-to form of identification. Sure, there have been lots of improvements in the world of identify over the last few years, but there’s still a constant flow of applications and websites that rely on this tried and true method of protection. Unfortunately, because it represents a single point of failure, it’s actually one of the least secure methods for providing your user is why they say they are.
There’s been a recent resurgence in alternate technologies to help protect your application’s users including a wide variety of two-factor solutions and things like federated identify providers. People are understanding more and more that a simple password isn’t enough. We see stories almost daily of some major company or group being hacked because of either bad passwords or bad password storage practices. Unfortunately, there’s only a limited amount of things you can do for the former (like more effective password policies), but there is a way to help with the second. It’s surprising to find out just how many companies and applications have made poor choices when it comes to how they protect their users’ passwords. There are even some that have made the disastrous choice to store them as plain text (it makes me cringe just thinking about it).
Security in cloud environments better enhanced in other ways
With compliance becoming an ever-increasing priority and hybrid infrastructures becoming the norm, many traditional IT practices must evolve or die. Perhaps a widely used practice that hasn’t kept up with the evolution of compliance requirements in increasingly hybrid environments is the jump server, often called the jump box.
The original theory for jump boxes made a lot of sense. Set up a jump box as a bastion host inside of your environment that everybody logs into and then you can “jump” to any of the other boxes or servers. The jump box would be a heavily fortified gatekeeper, ensuring that only the correct users could pass it. Audit controls would be placed on the jump box to track all user activity. For those that wanted to level up, multi-factor authentication could be installed at the jump box to make it harder for an attacker to leverage stolen credentials.
Taking a look at the usual suspects: SQLi, XSS & CSRF
As any PHP developer that’s been around for a while will tell you, there’s a certain kind of stigma that comes with the language. They’ll hear it from their peers using other languages that PHP is “sloppy” or that “it’s just a scripting language, not a real one.” There’s one other that seems to follow the language around as well—that it’s insecure. Sure, PHP’s not without its problems—but any language is going to have its share. Ruby’s had several major vulnerabilities in the press lately and Java has definitely had its own list over its extensive lifetime. People put down PHP for not being secure, but they forget that it’s not the language that makes for insecure code, it’s the developer.
PHP, by its nature is “meant to die” at the end of every request, so the developers don’t have to worry about some things that more persistent languages do. There’s still some common dangers, though, that you as a PHP developer should be aware of. The most common ones come from the well known OWASP Top 10 list. Here’s a quick look at how to help prevent just a few:
When will Adobe disclose the full extent of its breach to users?
Over the last week, the analysis of the Adobe breach has gotten more interesting.
The actual file itself has been available via BitTorrent. I found a torrent file and looked through it myself. If you’re interested, note that the torrent gets you a 4+GB zip of the actual 10GB of text.
Paul Ducklin at Sophos has published a very good analysis of the contents of that file. The summary is that each record has an account number, an account name, an email address, the encrypted password, and the person’s password hint.
The need to root out old data goes well beyond creating disk space
A couple weeks ago Brian Krebs announced that Adobe had a serious breach, of customer data as well as source code for a number of its software products. Nicole Perlroth of The New York Times updated that to say that the breach appears to be much bigger than thought and, indeed, Krebs agrees. Adobe themselves announced it first, earlier than Krebs’s first report in CSO Brad Arkin’s terse blog post, Illegal Access to Adobe Source Code.
By now, breaches are hardly news at all. All of us pros flat out say that it isn’t a matter of *if* you get hacked, but *when*. Adobe’s is of note solely because of the way that the news has dribbled out. First, the “illegal access” to source code, then the news of lost customer data to the tune of 2.9 million, then upping that to 38 million, but really actually (maybe?) 150 million. The larger number is expired accounts—or something.
Not just paying attention, but starting over
Security has to reboot. What has passed for strong security until now is going to be considered only casual security going forward. As I put it last week, the damage that has become visible over the past few months means that “we need to start planning for a computing world with minimal trust.”
So what are our options? I’m not sure if this ordering goes precisely from worst to best, but today this order seems sensible.
Stay the Course
This situation may not be that bad, right?
There's no such thing as perfect security, and we should stop sacrificing the good for the perfect.
I’ve had a day or two to play with my new iPhone 5s, and the fingerprint scanner is one of the nicer things about it. I like the added security of being able to unlock it with my fingerprint, because I was one of those people who could never be bothered to have a passcode on it before.
Of course, the news of the day is that some inventive folks in Germany have managed to unlock one of the phones by lifting a print from the glass of the display and using a variety of fairly low tech steps to create a false thumbprint from it. This should come as no surprise to anyone who understands how fingerprint sensors work. The 5s does more than some to prevent spoofing, but pretty much no fingerprint scanner is impervious to a determined attack.
What is sad to see is the conclusion that these hackers (and the press) have drawn. “Fingerprints aren’t a good method of securing data. You should never use something that you can’t change as a password. Always practice two-factor security policies.” Of course, if someone really wants to break into your phone, and is willing to expend the effort to do it, they can. If someone wants to break into a typical house, they can. If someone wants to steal your car, they can.