Raesene's Ramblings

User Friendly have been running a series of cartoons on password policies :)
Password policy at it's worst!
A great old one's approach to the problem of password complexity!
Passwords on monitors

The last piece of the puzzle when it comes to password policies is the account lockout . Also this is another area where a tighter policy doesn't necessarily lead to improved security. A lot of companies go for 3 incorrect attempts, and this does lead to a lot of lockouts on Monday mornings and consequently a lot of false positives in the security departments monitoring for attacks on authentication systems.
Again with this section of policy it's important to understand what threat is being mitigated. Account lockout is designed to mitigate online password guessing attacks.
Now given that if you have a password length of say 8 characters with a requirement for upper and lower case characters you've got a theoretical maximum of 52^8 combinations (reality will be obviously be somewhat less than that).
So realistically the risk of an online password guessing attack succeeding is pretty low, if the attacker doesn't have an insight into likely passwords that a user will choose.
So what's a good number for password lockout. Well Microsoft recommends 50, but I've got to say that I think around 10 is good for most circumstances. My reasoning here is that if someone can't remember their password after 10 goes, they've almost definitely forgotten it.
Of course the next part of this is what to do when you've locked the account out. Well if you've gone for a reasonably high setting on the incorrect password attempts, then I'd say in most cases lock the account permanently until the user has gone through the password reset procedure (establishing a good password reset procedure is a topic for another day!).
One problem with account lockout that's raised is the potential for Denial-Of-Service. If the username is predictable to an attacker they can iterate over the namespace and lockout all the accounts.
The mitigation for this depends on the architecture of the systems. If the system is inside a corporation then monitoring should track the attack and incident response should hopefully be able to track down the attacker.
However for Internet facing systems that's obviously not possible, so some other mitigation may be needed.
Two potential options for this are

• IP based lockout. Instead of locking the account for all users, only lock it for the source IP of the attack. This isn't perfect protection but may well work for many attackers
• Use multiple secrets. For example have a password and a secondary secret. Then only increment the incorrect login count if the attacker is getting the username and one of the secrets correct.

The next stop in my trip through password policies and some of the mistakes that are made is password strength (length and complexity).
It seems that for a lot of IT and IT Security people, there's one inevitable truth about password strength which is you can't have too strong passwords.
Unfortunately not true.
Like any security control password strength should reflect the environment that the system is deployed in and the likely threats it will face.
For most circumstances my feeling is that any password over about 9 characters with Upper and lower case alpha and numeric characters is overkill.
For this to be the case I'd say that the password should not be sent across the network in the clear either as plain text or a straight hashed value and should be stored in place in a salted-hash.
If you consider the threats, this will usually be more than adequate.

1. Online Brute-Force. This attack isn't best mitigated by password strength. Account lockout and alerting are a much better way to deal with this. For online systems I saw an interesting twist on this which was to only lockout the ip address the attack comes from as a mitigation of the DoS potential
2. Rainbow Table. The primary mitigation for this is to use salted hashes, as they mitigate this pretty effectively. However where that's not a possibility (off-the-shelf software) consider disk space required for the tables and the time to calculate. I've not seen any tables that go much beyond 7-8, and indeed one estimate I saw for 7-9 character passwords was that it would require 135000GB of space!
3. Offline Hash attack. This one is wheeled out a lot by advocates of extremely long passwords. One point I'd make is that in many scenarios if the attacker already has access to your password database, he's probably already broken in to your system pretty effectively! However even so, it's worth considering.
   Offline password guessing is done either through (hyrbid)dictionary attacks or straight brute-force. For brute force my experience has been that even with modern kit it gets too long to be practical for most attackers beyond about 8 characters. Dictionary attacks work very well if users choose dictionary password so it's worth investing in education/auditing to discourage this

So what does all that leave you with ... Well all of these attacks are reasonably mitigated in typical scenarios with 9 character passwords. Only problem is most people can't reliably remember 9 chunks of totally random information, so the key is to reduce the number of chunks whilst keeping up the number of characters.
There's a number of ways of doing this but things like passphrases like "414 million for that? We was robbed" are easy to remember (especially if you're Scottish) but very difficult to crack.

I jumped in earlier talking about password rotation policies without actually mentioning why I think password policies are so important, so I'll back up and cover that now.
The use of passwords as authenticators for computer systems has been around for a very long time, and for quite some period the security industry has had a focus on reducing their use, as their shortcomings have been well known. Single sign-on, identity management, two factor authentication etc etc have been themes for quite a while.
But here's the thing, passwords aren't going away, in fact I'd say that their usage is increasing.
At home we've got a hugely increasing number of websites offering us services, from social networking sites like Facebook and myspace to forum sites to e-commerce sites, and all of them use passwords (usually not integrated with any over-arching identity management system)
At work, there's the rise of application service providers and "software as a service" which leads to company staff accessing external websites for business purposes, again usually without identity management support...
So it means that getting your password policy right is actually getting more important.
The problem I've seen is that many companies don't actually risk assess their password policies. They set one level for users and one for "super users" regardless of the system location and other controls. Combined with that you get "best practice" principles that seem really inappropriate for most systems and it can be quite a mess....
Over a series of posts I'll look at some examples of where password policies could do with some attention, any feedback/comments welcome :)

I've been meaning to blog about some of the reading I've been doing recently on password policies, but an article in the latest Insecure Magazine tipped me over the edge into writing..
In the article on password management on page 59 the author mentions some elements of a "best practices" password policy which include password rotation every 30 days as a good thing.
I've seen this repeated in many places but I'm not sure where it came from. My opinion is that, in many cases, 30 day password rotation is actually a very bad thing, both from a user experience point of view and also from a security point of view. It's one of those things that gets put in password policies without any real thought of the consequences.
The reasons I've seen stated for rotating passwords are

1. Mitigate password sharing. This doesn't really hold any water, if a user shares their password then they can just share the next one. A much better control is to educate the users never to share their password no matter who asks. This also has the side effect of helping mitigate some social engineering attacks
2. Reducing the window that someone has to crack a password hash. There may be some circumstances where this may help out but really who's to say that it'll be a specific number of days for a password crack. From my experience of auditing windows passwords, you either get it real quick with a hybrid dictionary attack or rainbow tables(in which case the rotation doesn't really help, or you don't get it at all (if you've set password length over about 9 characters most attackers won't be able to brute force a password with a decently designed algorithm.
   A better mitigation for this risk would be to ensure that password hashes are protected in transit (eg with SSL) and on hosts.

Also password rotation has several possible side-effects which actively reduce security

1. Sequence passwords. Most users when faced with a password rotation will choose a sequence password eg ([password1], [password2], etc), so once an attacker knows one password for the user, they'll pretty easily guess the next one.
2. Helpdesk password reset fatigue. Password rotation (along with some other aspects of password policies I'll come onto later) causes a large number of calls to a help desk. From a security standpoint, we want a password reset request to be an alert that someone is trying to attack one of our systems, but if the people being made aware of that alert (the helpdesk) are swarmed with "false positives" in the form of users forgetting their passwords, inevitably real alerts will be lost in the morass. In order to make password resets an effective control, we should be trying to minimize the number of times that the process is invoked (while maintaining the security of the password system obviously)

There are other elements of "classical" password policies that are just about as annoying, but I'll leave them for next time.

There's an interesting story at The Register about the recent leaking of embassy credentials amongst others, by an individual in Sweden.
The story is that someone set up some Tor exit nodes and then sniffed the traffic that came out over them.
There's several interesting points that come out from this, I think.

• Understand the type of security provided by a system. Tor is not end-to-end encryption and you are trusting the exit node as you would trust an ISP router.
• What was done here can be done by any ISP employee. A Tor exit node is essentially like an ISP router. Anything that can be gained by sniffing a TOR exit node could also be gained by any employee of an ISP for the traffic that that ISP handles.
• Embassy users are logging on to their services in the clear!? The main problem here seems to be that embassy staff are logging on to e-mail systems in the clear over an untrusted network (the Internet). It seems odd that they'd go to the trouble of using Tor to anonymise their traffic but not go to the trouble of using SSL or an equivalent to protect their logon credentials end-to-end...

The Art of Scoping Application Security Reviews (Part 1) - The Business ｫ Mark Curphey - SecurityBuddha.com
Mark Curphys starting a series of posts on application security review scoping, which should be interesting reading (although I imagine it may annoy some people in the industry ;o) )
In this one looking at the business aspects I particularly liked the bit about "Bling Bling or Bang Bang" It's true to say that in a lot of cases the money spent getting consultants to write up reports could be better spent elsewhere, especially in cases where an internal team will be refomatting the output before presenting it to the business.
Also like some other people in the industry (Marcus Ranum being an example) Mark seems to have a flair for analogies. drawing the analogy from security assessment companies to the food industry was in many ways bang on.
There are "Chefs" out there, where you specifically want their services, not just those of the company they work for. That said I'm not sure any of the companies out there will want to be associated with being "food chains" !

TaoSecurity: Marcus Ranum Highlights from USENIX Class
There's some very good points here in TaoSecuritys summary of a Marcus Ranum session at Usenix.
I've not seen the original talk but the summary makes me wish I'd been there.
The point on the perimeter being a complexity management tool is very well made in reference to de-perimeterization. It's all very well saying that each individual device needs to be able to stand alone from a security perspective but it's still a lot easier to manage the security of the wider environment when you've got some control over what can get in at all, and the perimeter can and does provide that.
The points about quantification problems seem to have provoked a response from Alex . I actually think having seen these arguments come up repeatedly on blogs and on the CISSP forum and also having started reading "Security Metrics" by Andrew Jaquaith, that there's less distance between the people who are strong proponents of quantitative analysis and those who are proponents of qualitative analysis. One thing that has struck me in these debates is when you look at the examples on both sides they tend to be in different areas of security.
My feeling is that there needs to be a mix of the two styles depending on where they're most appropriate, but I'll reserve expanding on that till I've sorted my thoughts on the matter out better as it's a bit of a minefield...

Rational Security: On-Demand SaaS Vendors Able to Secure Assets Better than Customers?
An interesting post from Hoff on whether having data with SaaS vendors may leave you more or less secure overall.
I've had a couple of experiences of this over the years and I'll say that generally where I'm seeing data hosted out of the company using SaaS I tend to get less of a feeling of security rather than more.
A couple of reasons for this. Using SaaS adds complexity to areas like leavers/movers/starters procedures as there's another notification point for these, and as we know most companies aren't perfect at leavers policies, so you can introduce risks that people who have left can still get access to company data.
Also there's no really good way to easily assure the 3rd parties security. As Hoff alludes to, a lot of companies think SAS70 == Security, which just ain't the case (although it can be useful for getting assurance over the performance of some security related procedures). So you're left with either engaging in a lengthy assurance process which probably isn't practical if you have a lot of SaaS vendors, or relying on a combination of Pen Test/SAS 70/contract.
Of course, this is complicated even more where the SaaS vendor outsources some of their functions like site hosting, as then you have hierarchies of trust with each agent having similar difficulties in trying to assure the security of the companies they rely on.

Black Hat 2007 Multimedia - Presentation, Audio and Video Archives
Blackhat US 2007 presentation are up on the site now, great news for those of us not lucky enough to have been there, we can get some more details on all the interesting ideas talked about.