Changing The Game?

Aside from regular password change intervals, is there a way to mitigate offline brute-force attack?  Assuming an attacker uses any of a number of methods to grab a password hash, and that the hash isn’t some sort of weak LM silliness, an attacker is left with a long-running brute force process, depending on the computational power available.  For most organizations, a password change policy of 90 or 180 days would likely make the results of the brute force moot.

Given that offline brute-force is a realistic threat, isn’t a password change policy a reasonable control?

@Steve

It sounds like a realistic threat, except for the fact, that if someone has been able to get your password hashes, then they are unlikely to need to brute force passwords. They already have the access they need to get to the data that they want. If you own the authentication system, passwords no longer matter. Even if they need or want passwords, they now have the ability to capture them at will.

@David

The specific scenario I was thinking of involved cracking an Active Directory domain member, and then dumping the hashes of the last 10 logged-in users (which is used to authenticate users when the domain controller is unavailable).  There’s a good chance that a regular user’s PC will have had a Help Desk or other more-privileged account logged in within the last 10, and by cracking that hash, the attacker would gain access to higher privileges.

It’s only one example, but I expect others could be brought up.  I certainly don’t think the concept of password aging can be dismissed out of hand.

Mort,

“They believed us, every single time, they shelled out the bucks”

You have clearly worked in different places than I, but I’ve never seen a place where security got everything they asked for.

Also, 90-day password change policies are stupid in >90% of scenarios. There are probably some DoD scenarios under active attack where they make sense. The clowns who insist normal business systems need 30 or 90 day password expirations don’t mean *all* users should disbelieve *all* professional security advice.

Steve,

If your passwords are realistically brute-forceable in 90 days, they’re too short.

Mort,

There are various ways you might get a UNIX /etc/shadow file from backups, so reversing password hashes is a real threat.

@Steve

Okay so lets take your scenario. The question you have to ask, is how long is the hash going to stand up to attack. With a strong hash, it’s going to be a heck of a lot longer then 90 or even a 180 days, possibly years. In that case, what’s the justification for changing it on a 90-180 day schedule?

On the other hand, if the hashes are susceptible to a rainbow tables attack we are looking at seconds to minutes to crack. This leads to potential scenarios such as a theoretical attacker could be in your system for upwards of 90 days which means a world of hurt and if they are in that long a password change isn’t going to keep them out. Realistically though, what this means is that you now have a more complex risk question around how likely is it that someone is going to break in and get the hashes and how long are you willing for them to have use of those passwords? We at this point have little to no data on how likely this sort of attack is to occur so we can’t even take even a bad guess at if 90 days is a good number or a bad number. But until we have some data, we’re just making stuff up so make ourselves feel like we’re doing something.

Based on all the recent breach reports and investigations, it doesn’t look like password cracking is a major vector anymore (I’m not willing to stand behind that statement, but that’s my reading of these reports).

With modern systems (no more NTLANMAN) is it really a risk? Is that risk greater than the cost of password rotations?

Well, this kind of highlights the problems you were saying, doesn’t it. 

Business doesn’t “get” us, and now we’re arguing about how much we need to piss off users with password rotation (which is probably the least of our problems).

To add to your bottom line, David, regardless of which “line” you take concerning compliance (piss & moan vs. begrudging acceptance) the important thing to do NOW is force these standards bodies and policy makers to include:

1.) Data sharing
2.) A set of formalized metrics and models.
3.) Evidence Based Evolution for #2 based on #1

It shouldn’t matter what you think of compliance, you need to be pushing for those.

Hugs & Kisses

Alex

I don’t want to take this position too aggressively, because I don’t actually have a strong feeling on password aging, I just think it’s a reasonable control in some environments.  I’d be willing to bet that most small-to-medium businesses don’t have complexity requirements, either, which would moot this point, since the crack would be trivial.

Some experiments have been done with EC2 on how much it would cost to crack some (good) passwords in the cloud:

http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html

There has also been a fair amount of activity around nVidis’s CUDA in the password cracking arena, for the more modest budget.

Just as an example of the CUDA technology mentioned, not to chime in on the 90 vs. 180 vs 380 days:

http://blog.red-database-security.com/2009/11/29/ighashgpu-cracking-oracle-passwords-with-790-million-passwordssecond/

We pentesters crack passwords all the time. However, basic crackonomics shows that it’s not worth it to leave a job running for 90-days, so that’s not a justification to change passwords.

There are other reasons. Users are stupid and choose the same password for their corporate accounts as their online accounts. Password rotation breaks that. I’m not sure the exact cost/benefit breakdown for password rotation, but I’m sure it’s not as simple to calculate as you might imagine. In any case, we never recommend it.

We are increasingly seeing “security compliance” managed separately from “security”. Security compliance is often driven by the audit subcommittee of the board. A lot of our customers are more afraid of being out of compliance than they are of being hacked.

I know of nobody who claims that being compliant means they are secure. It’s one of the one-hand-clapping arguments of the security community, there’s nobody who seriously debates the other side of the argument (although, I admit, maybe I don’t run in the right circles to hear the other side of the argument).

Great debate, gents!  Here’s my commentary: http://newschoolsecurity.com/2009/12/can-risk-management-guide-policy-regarding-password-change-frequency/

I like to think of password changing as an insurance. It helps prevent the lingering knowledge of passwords to bite you in the ass 6 months or 6 years into the future. That would include people who quit and take shared passwords with them, share them with others (“please check my email!”), get them snarfed when they log into a VPN or email from an untrusted network or system, get them snarfed by malicious or curious employees who crack their local SAM, or simply have them leak out from a lost/stolen laptop…the weight of which all depends on how important a target you may be. And, as mentioned, it breaks the trend of re-using the same password for everything, in which case you’re only as strong as your weakest use (that non-SSL online forum with the 2 year-old forum software and non-encrypted database run by kids with no ethics…).

It all helps demonstrate that you can be confident that every 90 days, passwords are only known to those who set them. Of course, then your timer resets and over time confidence reduces, until you repeat the whole process again. And if you don’t change them, you fall further down the slope of being able to prove someone did something, i.e. non-repudiation and, what some people will argue is highly important, attribution. :)

And while pen testers will do crack runs every time, attackers still don’t necessarily need to unless you’re targeting someone and latching onto their laptop while they’re at the hotel bar. There are still other ways to get things, but cracking passwords certainly gets you pretty high value when you do bother. At least that window might only be 90 days…?

It’s a benefit that the security measure is easily understood, demonstrated, and executed by non-technical managers!

Anyway, back to the issue and not a small example! :)

I think we’re on the same page.  As an industry we need to communicate more clearly.  It wasn’t my intent to fault any information professionals as much as I’m hoping that we all will push a bit harder for the right conversations in the future.  We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue.  We’re yelling in the wrong language.  We just need to put that effort into learning their language and communicating more effectively.  How is it that we can read HEX in real time but can’t converse with a MBA at any time?

As for the seemingly more contentious point – perhaps in my post I should have spent more time defining this better.  I don’t think any real security practitioner thinks about compliance as the solution.  I do think that we need to accept responsibility for letting our organizations fall into the trap thinking that being compliant is an end-state position rather than compliance simply being another set of tools.
 
Believe it or not I’m actually not completely against compliance activities, just the poorly implemented, short term focused and overall plain silly way so many organizations approached compliance. Of course I have seen a few organizations along the way that had planned effectively and compliance activities actually enabled some incremental security growth – especially in terms of understanding the environment they are trying to protect.

With that said, the actual point I’m trying to get across is much larger… we’re focused on compliance or security on a playing field that is never going to allow us to really have a chance at winning the game.  I think it’s time to start thinking about securing and measuring what we have AND about what the playing field should look like moving forward – without the constraints of the current state.  We can completely alter everything about the current environment (we can change the weather, the states of matter, etc).. 

What would IT security look like if we spent as much time on those thoughts as we do on compliance tools, dashboards and monitoring?

I’m not sure I fully agree with you here, David, though in some cases it was the beginning of a paragraph where I took issue, and the end of the same paragraph where I found agreement. A couple points of contention…

You said: “Where we have failed as practitioners is in making this distinction and allowing vendor and marketing BS to convince business folks that because they are compliant they are of course secure.”

People believe what they want to believe, typically based on what most reinforces their pre-existing opinions. To make matters worse, organizations typically turn a deaf ear to their own people in favor of those outside their organization, as irrational and insane as that may be. They wantonly ignore those who see the organization for what it is in order to hear fairy tales from those who see the organization they way they’d like it to be (that is, adorned with their products, of course).

I also would not say that we practitioners are “allowing” these faulty perceptions to exist. We’re doing what we can to fight them, but we’re not being successful. Why? If I were to guess, it’s because we don’t have the resources necessary to leverage the same techniques marketeers use in pushing their own agenda. On a large scale we call this Congress and Lobbyists. ;)

You said: “...the failure here is that we told the business, repeatedly, that if they installed this one silver bullet (firewalls, AV, IDS, and let’s not forget PKI) they’d be secure.”

What rational, reliable, mature security professional in their right mind is selling point solutions as “silver bullets” these days? Is this really still a problem, at least from the practitioner perspective (putting aside vendor marketing)? This is a patently unfair accusation. Unless, of course, you’re talking about analysts and how they position and promote technology solutions instead of promoting a balanced approach. The same goes for FUD (unless you’re Anton, apparently)...

As for your password example, what’s your point? Here again is another compliance-driven requirement that has been foisted upon us. Where did it originate? In somebody’s confused notion of how to address a specific threat (a notion that makes auditors happy, but with no basis in sound reasoning or measurement). However, don’t blame this on current practitioners. It’s lore, now; part of the mediocrity that is best practices. I think this rather reinforces the point that we really do need to throw out everything we’re doing and start with fresh eyes and ears.

I think we’re on the same page.  As an industry we need to communicate more clearly.  It wasn’t my intent to fault any information professionals as much as I’m hoping that we all will push a bit harder for the right conversations in the future.  We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue.  We’re yelling in the wrong language.  We just need to put that effort into learning their language and communicating more effectively.  How is it that we can read HEX in real time but can’t converse with a MBA at any time?
As for the more contentious point – perhaps in my post I should have spent more time defining this better.  I don’t think any real security practitioner thinks about compliance as the solution.  I do think that we need to accept responsibility for letting our organizations fall into the trap thinking that being compliant is an end-state position rather than compliance simply being another set of tools. 
Believe it or not I’m actually not completely against compliance activities, just the poorly implemented, short term focused and overall plain silly way so many organizations approached compliance. Of course I have seen a few organizations along the way that had planned effectively and compliance activities actually enabled some incremental security growth – especially in terms of understanding the environment they are trying to protect.  Even with that the point I’m trying to get at is larger… we’re focused on compliance or security on a playing field that is never going to allow us to really have a chance at winning the game.  I think it’s time to start thinking about securing and measuring what we have AND about what the playing field should look like moving forward – without the constraints of the current state.  We can completely alter everything about the current environment (we can change the weather, the states of matter, etc).. 

What would IT security look like if we spent as much time on those thoughts as we do on tactical thoughts, compliance tools, dashboards and monitoring?

Greetings & Salutations,

SECURITY—I::::::::::::::>

It’s a process, not a product.

It’s a marathon, not a sprint.

It’s a war of attrition to some degree.

My computer has enough resources (think of it as a piece of real estate) to treat parts of it as Embassies.

If I give you a login on my OpenBSD 4.6 laptop, and make some further adjustments to suit your needs, you basically get a shell that can help you stay turtled come hell or high water.

I can and have managed (systems admin) a fleet of mobile & workstation machines before, and I have only gotten better at it since then.

So. That is how negotiations and diplomacy start. (Or call it Duplomacy, that’s always funny.)

Agent Provacateur, I’m talking to you, too. And I’m talking to others as well. So hold your horses and think about how many times YOU would prefer me to replace my hard drive, because each time, it costs me like $50 and 4 hours of the most fun times I’ve ever had.

Seriously. Reinstalling on my compy is like going to a hooker. Even if I have something terminal lurking in my BIOS, not everyone has the key to that particular minerva.

So change your passwords, I’m starting to lose patience, I am **not** here to swipe your stuff or stalk you, I am just here to pick up my mail and get more coffee.

Thanks,

- Jack Merlot

@mortman. If we can agree that risk can be defined as the probable frequency and magnitude of loss, then I think we can find numerous examples of how changing a password on a frequent basis can impact the “frequency” and to an extent the ”magnitude” factors of the risk; thus reducing overall risk.

The first example I have seen is in scenarios where employee A shared their password with employee B, who subsequently left the company. Employee A had privileged access to confidential data. Former employee B continued to access resources using employee A’s credentials – until employee A changed the password. Former employee B calls helpdesk to get a password reset and fails identification procedures. The fact that employee A changed the password prevented former employee B from further accessing customer information (frequency) as well as put in end to the number of records that were being accessed in an unauthorized manner (magnitude; less consumers to notify).

If a company is relying on the frequency of changing passwords as their sole control to prevent and detect unauthorized access to information – that is a problem. Account lockout, lockout duration, password complexity, location-aware authentication, are all additional controls that in some cases negate the need for changing passwords.

Finally, changing passwords on a frequent basis for IDs that are “generic” in nature (DB related, web services, other app / auth interfaces) is critical. These are the IDs / password combos that can have access to thousands if not millions of records.

Let me know if I am misunderstanding the problem statement.

I think it is pretty clear that password changes reduce risk by increasing the cost of attack, albeit slightly. I am not convinced, however, that it is worth the effort. Full analysis can be found here: http://spiresecurity.com/?p=1093.

Pete

Fascinating discussion.

There are three points that I think are key here.

First, LonerVamp’s point confidence that the password provides security is not a static value, but decays over time.  I think that is a useful restatement of the question, rephrasing it from a choice between two arbitrary standards to a question that can be studied with data.  (of course isn’t that the core of Mr. Mortman’s point?).

Second, password cracking may be more relevant to elevation of privilege than to acquisition of privilege.  Slightly different threat model. 

Third, and most important, analysis of security standards relies on a coherent threat and risk model.  Except in trivial cases, you can’t exploit hashes unless you already have access. But are there ways to get hashes? Interception of remote workers & VPN? PWDump from a compromised machine? Fundamentally we’re analyzing defense in depth - where no protection stands alone, but is backed up by other protections.

I know that if I were the person responsible for accepting risk that I’d be more comfortable with a policy attempted to exploit passwords, and forced a password change on any password that was cracked in less than a week. (Actually, I’d be most comfortable if they ran the password cracking long term, spotted the inflection points in the curve and forced a change on anything under the curve).  That is going to cull out the easy passwords and force the attacker to spend time (his opportunity cost). 

Without real data to back the various hypothesis, the discussion will not terminate.  And that is the reason for compliance.  The people involved in this discussion, if given an infinite funding line, could acquire the data, identify the risk drivers, build a model and come up with a standard - to achieve risk X, change passwords every Y hours.  Six months later we’d have to acquire a new infinite funding line and repeat the study to capture changes in practice and attack techniques.  Since most of us don’t have an infinite funding line available every six months, we pick an arbitrary number.

Which takes us over to the discussion at Rybolev’s blog.

For those who don’t read Rybolov’s blog, @Mark Wallace is referring to this post: More on the Rybolov Information Security Management Model (http://www.guerilla-ciso.com/archives/1406)

@Chris Hayes

You make a great point. Namely that there are other risks other then passwords being cracked that need to be worried about, such as password sharing. Other concerns, include password theft from phishing and whatnot.

My concern is still that 90 days is completely arbitrary. We as an industry made up a number that made us feel happy on the basis of absolutely no evidence whatsoever that 90 days is useful. Now we are stuck with it because it is ensconced in various regulatory requirements such as PCI, so now this debate is moot (cue 1980’s Jessie Jackson SNL skit).

“Finally, changing passwords on a frequent basis for IDs that are “generic” in nature (DB related, web services, other app / auth interfaces) is critical. These are the IDs / password combos that can have access to thousands if not millions of records.”

This is an important point. It’s a good idea to change these passwords when an employee who had access to that data leaves the company, or if you have reason to believe the system was compromised. Though even in the case of compromise, password changes wouldn’t be my highest priority since an attacker can just ride the existing connections between servers without ever compromising accounts.

But other than that, how often should we change those? PCI doesn’t properly specify as far as I can tell and by all reports no one audits there accounts.

This debate on the email question inspired another post on controls vs. outcomes: http://securosis.com/blog/security-controls-vs.-outcomes/. It was too much to squeeze into a response…

@David Mortman – Thank you for following up. Frequency of password change is a control. From a threat modeling perspective – the frequency attribute is influenced by those controls before it (access to the login screen), inline with it (complexity, lock-out, etc…) and behind it (authZ, number of records that can be accessed). We also have to be mindful of previous loss events, the classification of the data, and the list goes on. I mention all of this to say that there are many factors to determining what is an acceptable frequency – I have only listed a few – and these may vary from industry to industry or technology implementation. While I cannot answer why 90 is the “standard”, I am willing to bet that most security professionals are not ready to get rid of passwords altogether – in absence of no other authenticator; it surely would not stand up to legal or privacy scrutiny in terms of due diligence.

Next, we have to be mindful of all the various authN repositories out there. Not all companies are fortunate to have Microsoft AD / Novell E-Dir as their primary authN repository for ALL their applications. An example that quickly comes to mind is RACF. In a lot of cases there are limitations to id length, password complexity, and other aspects of id / password attributes that we take for granted with common LDAP authN repositories. And no, rewriting your apps on the mainframe or migrating off the mainframe is usually not a reasonable option. So, backend authN repository is also a factor in determining password frequency.

Finally, I do agree that frequency of password changes should be commensurate with the level of risk with the most common use cases (consumers accessing apps, employees / contractors accessing apps, data classification, legal/regulatory requirements). This is easier said then done.

@Chris Hayes

We are so on the same page. And you are right, this is much easier said then done. As you said, there are a ton of factors that go into such a calculation. The question is how do we get to a more reasoned estimate? You have a ton of data from your employer, any chance you can do a FAIR analysis and tell us what you get?