Passphrases

This was from a little while back, but I hadn't got around to posting it yet. Dan Kaminsky offering a different view of passwords:

"You know what's amazing about passwords? They totally work," Kaminsky said. "The fundamental 'win' of a password over other technologies is its utter simplicity and mobility."
An easier way to make passwords more secure, Kaminsky said, is to mandate 12-character passwords, but make them all lowercase letters so users can create passphrases that are long but easy to remember. Increasing the length of passwords and thereby making them harder to crack is critical, he added, but it has to be done in a way that doesn't overly tax the human memory. 
He certainly brings up a good point. The problem may not be passwords, but bad passwords. And why do we get bad passwords? The same reason we get single passwords used across multiple systems or people using their birthdays as PIN numbers - "Password1" or "P@ssw0rd" is easier to remember that "w4dHu92#".

But will passphrases change that? It will involve a seismic shift in mindsets and many users having to 'unlearn' what they've been told previously. The 'passphrase' movement has been around for a while and the first reaction from users when you say "Now your passwords have a 12 character minimum" is generally not positive - even if you do away with the complexity requirements. People already forget their passwords with alarming regularity, I'm not sure if passphrases will be must easier to remember.

Passphrases have their limitations too - they don't help with password reuse, and won't stop a user changing "fourscoreandsevenyearsago" to  "fourscoreandsevenyearsago1" on their next passphrase change.

But I do agree with Dan that passwords work better than we probably give them credit for, and maybe passphrases will work a even better.

OWASP Top 10 2013 Release Candidate

Release candidate for the 2013 OWASP Top 10:

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20RC1.pdf

Rearranging Deckchairs on the Titanic

I heard this term for the first time the other day, and while I think there are several analogies from the Titanic that can be drawn upon for describing concepts in information security, perhaps few are as apt as this. It implies, of course, the futility of rushing around making minor adjustments in the face of impending disaster. Counteracting this requires you to have a broad picture of the security issues in your area of responsibility so you can focus on avoiding the iceberg toward which you are currrently heading at full steam. It means focussing on the highest risk issues first and letting the minutiae go for another day.  If you are a network operations guy this means doing away with unencrypted protocols for administration before changing the enable secret on the router, if you are a developer it means fixing the SQL Injection vulnerability on the login form of your app before fixing the difficult to exploit XSS bug on a page only accessible post authentication.

The US State Department has a very effective model for this which they use for vulnerability management in their unclassified network, it is described in some detail here. There are three main components to this system, continuous monitoring, a weighted scoring system and continuous feedback to both those responsible for making changes and those reponsible for overseeing the security of the organisation.  Interestingly it lists as one of it's objectives 'inspiring competition' which I think could be a very useful way of incentivising security initiatives, but that's a topic for another post. The key component as it relates to this post is the continuous nature of the feedback, administrators are sent one task (the highest priority for the systems which they are responsible for) to remediate on a daily basis. The scoring system operates at a operates at a host, site and enterprise level, allowing the feedback to occur at all levels safely guiding the ship around the icebergs.

While the scheme described above does its best to objectify the security changes to be made, situations will vary and what is critical in one context will be less so in another, the important thing is that you do the assessment and make the changes in a sensible order. Sometimes business pressures or regulatory compliance will mean that these priorities will be changed but at least the trade off is understood. If you are placed in a position where you need to meet a compliance requirement perhaps use it as an opportunity to make material gains in your security posture i.e. comply with spirit of the law and the letter.

powered by Blogger | WordPress by Newwpthemes | Converted by BloggerTheme