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.

Internet Security Threat Report 2014

More from The Register

next story
Docker's app containers are coming to Windows Server, says Microsoft
MS chases app deployment speeds already enjoyed by Linux devs
IBM storage revenues sink: 'We are disappointed,' says CEO
Time to put the storage biz up for sale?
'Hmm, why CAN'T I run a water pipe through that rack of media servers?'
Leaving Las Vegas for Armenia kludging and Dubai dune bashing
Facebook slurps 'paste sites' for STOLEN passwords, sprinkles on hash and salt
Zuck's ad empire DOESN'T see details in plain text. Phew!
SDI wars: WTF is software defined infrastructure?
This time we play for ALL the marbles
Windows 10: Forget Cloudobile, put Security and Privacy First
But - dammit - It would be insane to say 'don't collect, because NSA'
Symantec backs out of Backup Exec: Plans to can appliance in Jan
Will still provide support to existing customers
prev story

Whitepapers

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.
Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.