Skip navigation.
Home

Example Risk Analysis on Allowing Plain Text Passwords

This article is based on an email discussion that took place on the SAGE-AU list in late May 2007. It was prompted by a somewhat less than satisfactorily explained query I raised, that suggested that it can be possible to have perfectly secure systems without using encrypted authentication. eg Still using Telnet.
The below is a slightly tidied up version of the emailed response I gave when I was asked to demonstrate the risk analysis used. The basic premise of this novella, is that you don't always have to lock down everything. And in some cases, doing so is even worse then if you had done nothing.
The target audience is and was Systems Administrators, though others may also find the information useful. If some of the context doesn't make sense, do be aware this is edited from the original, and I may have inadvertently pulled some bits that were necessary... Sorry. Let me know, and I'll add a fix.

So with the introduction and context set, on with the show!

Some quickish IT Security Theory to ensure we're all more or less on the same page.

CIA. Confidentiality. Integrity. Availability. These are the three pillars of all IT Security.

C : Keeping Secrets
I : That what you wrote yesterday is still the same tomorrow
A : That you can use a system at all

In general no one of Confidentiality, Integrity or Availability is more important than the others. You may have a 99.99999% secure system, but if it is in a locked box at the bottom of the ocean and no one can use it? It's a useless system.
So you win on Confidentiality & Integrity, but lose on Availability. There are cases where one or more don't apply but they are usually more of a reduced focus than truly don't apply.

Defence, for example, typically has an obvious focus on Confidentiality – keeping secrets. Dur. No surprises there. But war fighting systems aren't any good if they're unavailable. Attacking the opponents Command & Control is pretty common in warfare. Ditto integrity. eg Radar Jamming and other games.

So what sort of things do we look for in this style of Security Risk Analysis?

  • Possible attackers (Who)
  • Vectors of attack (Threats)
  • Capabilities (Likelihood) of Attackers - eg Me threatening to nuke someone. Zero Capability of same.
  • Vulnerabilities - such as plain text passwords
  • Existing Defences (Mitigating)

And probably a few other areas that memory fails me on. Smile

You enter all this highly subjective data (Managers will give different answers to Technical Staff. That's expected.) into tables and from that draw sums and conclusions as to where best to expend resources.

There are two main things we want to see out of a Threat Risk Assessment:

  1. That we are not overspending to secure a given system.
  2. That we haven't overlooked any areas that should be secured.

#1 is basically: You don't spend $1,000,000 to protect assets worth $10,000. This is the key to this article that I would draw peoples attention to. Too many people want to spend every possible resource protecting stuff that doesn't need protecting... just because they can. eg. It can be cheaper to let equipment get stolen than try and lock it all down. Wrap your head around that concept. Smile

#2 is basically, you haven't spent enough.

Finding “holes” in anyone's Security is relatively trivial. That's not the point. The point is to find holes that are likely to be exploited. And close those. Cheaply.

So with all that for background reading...

Problem:

Is it acceptable to use plain text authentication to mange remote servers? Specifically, plain text accessible only, management ports on servers, routers etc.

Analysis:

To be able to get passwords off the wire, you need to sniff packets. Or have root access on the Remote or Local servers. If the latter - game over anyway.
If the former? You need some sort of physical access. Possibly remotely controlled.

Who could or would do such a thing? The field is big, but rapidly reducible.

  • Local staff - well if they do this - you're screwed either way - they have access to the password(s) in case of emergencies. Or the power to directly modify data.
  • Remote staff - pretty much ditto
  • Joe Random Attacker – of varying skill levels
  • Trojans etc

Balanced by?
Suppose someone can sniff your network completely undetected. They don't need your passwords any more. Such an attacker can see any and all data flowing over the network they sniff.
So what are you now protecting? Integrity usually.... You're already dead with Confidentiality, and to a certain extent, Availability.

Existing Environmental Constraints?
Not perfect. But moderately extensive Physical and Personnel Security. The fibres run through less secure Telco pits, but
(a) good luck identifying which pits; and
(b) Good luck identifying which fibre.

Also, if you can get to that level, are there perhaps more attractive targets? Yup. So wouldn't an attacker prefer them instead?
Recall the joke about the guy who only had to out run the other guy, not the lion? Same Same.

You put locks, bars and alarms on your home, partly, for the same reason. Not to stop someone burglaring your home, rather to make your neighbours place look a more attractive target. Harsh. Brutal. Accurate.

Defence in Depth was raised.
What does this actually mean. In a security context, much the same as elsewhere. In essence: Deter. Delay. Detect.

  • Make it hard enough from the outside that attackers go for an easier target.
  • Slow them down if they do attack.
  • To make it easier to know if someone's has been successful or not.

SSH is a Deterrence... to sniffing. Not to brute forcing a password. Is no real advantage to Delay - brute force - tho key exchange can help - but that also just shifts the brute force problem elsewhere.
No real advantage to Detecting. Does this mean SSH is no good. No. Smile Rather do be aware what it is doing for you.

The other part of a sniff attack - how long do they have to be on the wire before the passwords are used? If every 5 minutes - easier. If every 6-12 months, that gets a *lot* harder. In this case the latter is too often.

Switched networks can make life a lot more difficult for sniff attacks. Anyone that has switch physical access can pretty much screw your life in other ways anyway. How many of us monitor logins to privileged accounts and the like? Looking for accesses from odd places/times etc. This is where auditing comes in handy. Detect.

eg Safes. They have that funky paint job on them for a real reason. To make it easy to detect if someone has brute forced their way into the safe. Or similar. Just knowing you've been compromised, and hence can react, can make a bad situation a lot better. Of course the front door blown off can be a Big Clue too. Wink

Or a simple thing like arpwatch. Seeing if and when new machines appear on your network - or segments of a network. Huge clue that funky stuff is going down. Were you expecting that new machine? Why/Not? This may not always be achievable...

FWIW? Most of the work we did in Defence Security was not laying down the rules, but rather trying to balance competing needs and still have a workable system - within budget. Preferably a long way under budget. eg. Beef physical security, to accept lessor logical.
Securing "Top Secret" DOS PC's being a classic case in point. PC on a trolley into a large vault at the end of the day. Work done in lockable/controlled access room. More ... exotic issues eg TEMPEST. No Network. FD's controlled as per usual classified media rules - backups to FD. Eventually removable HDD's made life a lot easier. Lock-up the HDD alone vs entire PC. But even then removable HDD's were seen to be too expensive and alternate solutions had to be found to protect very large classified networks.
The point being, don't even try and fix the Logical Security Issues. Too Hard. Instead, replace them with solutions from the Physical world. Problem Solved. Thinking outside the square if you will.

So far I have yet to mention one of the biggest parts of any Risk Analysis: Damages.

If someone did get into the ALOM ports what's the worst they could do? Lots actually, but only to the servers and the data they serve. No lives would be lost. No sensitive data exposed. No direct financial losses. Just a lot of embarrassment and the sounds of Steve eating his words. Smile
Embarrassment ain't good, but it's typically way down the list of priorities.

It's not a case of "who cares". But it's also not a case of drop everything.

So in Summary:

  • Usage of the plain text passwords is (very) rare.
  • Those who could do this won't via Clearances/Trust/Contractual Penalties/Ethics/Desire or Need/Process & Procedures etc.
  • Also: Those Others who could, already have access to the passwords anyway.
  • Those who have physical access can do far more damaging things anyway. So why bother on this issue - better to fix the bigger problem.
  • Those who would like to, have no effective way of being able to put it into practice.
  • There are more attractive targets in the same environment.
  • Extensive Physical and Personnel Security protect the more critical parts of the environment.
  • Logically behind extensive firewalls and IDS systems
  • Extensive "funky" detection to, hopefully!, detect funkies.
  • And even if someone did get access? Damage? Minimal, and lots of fixes in such an event.

Keep in mind that this is for a fairly specific case. I'm sure (and know) of others with similar setups. Same same.

I am NOT advocating that plain text passwords are acceptable. Bad habit forming for one. But don't get too hung up on things that are risk acceptable without any further effort. It doesn't need to be perfect. Just good enough. For your data and your needs.
What I would advocate for my existing systems, wouldn't be anywhere near enough on other systems I've looked after. Or conversely, would also be overkill for the same systems. Completely different risk profiles. It Depends.

In the example above, it is possible to do more to secure the plain text authentication. eg Use another machine at the remote end. SSH into that and then telnet – reducing the scope for sniffing.
But this also raises weaknesses and problems. Another server to manage for one. And more expense for something that is rarely used. Worth it? I would argue?... not.

Clear as mud? Laughing

Syndicate content