Feeds

Security damn well IS a dirty word, actually

Wash your mouth out with TLS 1.2

Internet Security Threat Report 2014

Sysadmin blog An interesting feature popped up on Ars Technica recently; website journo Nate Anderson discusses how he learned to crack passwords.

The feature is good; good enough for to me to flag it up despite that journalistic competition thing*. That said, the feature gently nudges – but does not explore – a few important points that are increasingly critical to consider in the context of any serious discussion about IT security.

In his feature, Nate describes himself as having learned to become a "script kiddie." While I won't dispute the nomenclature, reading the feature left me with the impression that he felt that tool chosen was an important part of what separates the script kiddie from more well versed malefactors.

The difference between a script kiddie and a decent cracker isn't the tool used. It is the time taken to understand how a tool works, why it works that way, what its limitations are and - ultimately - the effort made to increase the tool's efficiency and/or likelihood of success. Nate may have started his journey out as a script kiddie, but I suspect he's put far more thought into this than most script kiddies do. Were he to pursue this "addictive" line of investigation for a few more months, he'd be well on your way to what – in the 80s – we called a cracker.

The terms have been diluted over the years. A cracker was someone who put a lot of time and effort into breaking digital locks. It required a fair amount of knowledge to accomplish but was still a focused pursuit. A hacker – using the old school technology – would take this same iterative experimental approach to hardware. They would see software and hardware as two parts of a single whole.

For an old-school hacker the goal was to learn. The reward was solving another puzzle. These people still exist today; though increasingly underground as curiosity itself seems to be rapidly becoming illegal.

Wave your hands

Google Self Driving Car

Google's Self Driving Car: a security problem waiting to happen?

Computers are not magic. It is simultaneously a simple truth and the hardest element of their operation to intuitively grasp. There are so many layers between today's users and the underlying transistor logic that the operation of computers legitimately seems like magic, even to those who've spent a lifetime in the field. (Be rational all you want, printers were sent from hell to make us miserable.)

The problem with computers today – as with yesteryear – is the abstraction of these operating fundamentals from the usage of the device. Despite evolving existing interfaces, periodically reinventing the wheel and even changing form factors we are actually pretty bad at abstracting away the underlying flaws of computer design such that end users don't need to know how the widget works.

If you don't know how the widget works, you are ultimately going to be vulnerable to some security flaw you didn't even know existed. Despite this, proliferation of computers has trebled; the growth of deployment seems logarithmic with no asymptote in sight. Computers are in everything from our cars to our phones and soon our watches and even our eye glasses. If we can't secure the mess we have today what hope can we possibly have of locking down the much hyped internet of things?

It's dead, Jim

Anderson correctly highlights that the fragility of passwords is frightening. Password cracking software is shocking in its ease of use. What should be more frightening – but hasn't sunk in yet for most – is the ease with which virtually every other security mechanism we employ can also be compromised.

From encryption at rest (via RAM grabs, amongst others) to SSL/TLS (via, apparently, everything) on to nearly every other storage and transmission mechanism we've invented; the IT industry seems to birth crypto mechanisms that are really only practically secure for a few years - a decade at best.

More frustrating than this is that we do generate solutions to known vulnerabilities on a regular basis. In many cases they simply remain unimplemented. Consider the shocking lack of support for DNSSEC, or the fact that amongst the mainstream browsers TLS 1.1 is only enabled by default in Safari and Chrome while TLS 1.2 isn't enabled by default on iOS devices. (There's a good discussion on why here.)

The economies of most nations depend on the security and trustworthiness of these authentication mechanisms and yet the implementation of newer techniques is constantly held back. The multinationals making the gear we use circle each other and growl; each is looking to exploit the weaknesses that affect us all to their individual advantage.

Ultimately, I don't think education alone will help here. Some combination of "keeping one step ahead" on the cryptography front has to be combined with a UX that abstracts the "hard stuff" away from end users. As much as I'd love to teach 7 billion people proper password hygiene, I suspect this isn't the correct path.

Defeating security mechanisms is a challenging puzzle that offers wealth to those who accomplish it. Creating new security mechanisms – or fixing old ones – is hard and few are willing to engage in the activity unless a clear monetary advantage can be gained. We need a fundamental rethink regarding the economics of IT security. The market as it stands today isn't delivering. That failure promises to be a problem for us all. ®

*Though we'll put the link down here, eh, Trevor - Ed.

Beginner's guide to SSL certificates

More from The Register

next story
The cloud that goes puff: Seagate Central home NAS woes
4TB of home storage is great, until you wake up to a dead device
Azure TITSUP caused by INFINITE LOOP
Fat fingered geo-block kept Aussies in the dark
You think the CLOUD's insecure? It's BETTER than UK.GOV's DATA CENTRES
We don't even know where some of them ARE – Maude
Want to STUFF Facebook with blatant ADVERTISING? Fine! But you must PAY
Pony up or push off, Zuck tells social marketeers
Oi, Europe! Tell US feds to GTFO of our servers, say Microsoft and pals
By writing a really angry letter about how it's harming our cloud business, ta
BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
Don't worry about that cable, it's part of the config
Intel offers ingenious piece of 10TB 3D NAND chippery
The race for next generation flash capacity now on
prev story

Whitepapers

Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Getting ahead of the compliance curve
Learn about new services that make it easy to discover and manage certificates across the enterprise and how to get ahead of the compliance curve.
Top 5 reasons to deploy VMware with Tegile
Data demand and the rise of virtualization is challenging IT teams to deliver storage performance, scalability and capacity that can keep up, while maximizing efficiency.