Re: Best practice vs. "We have a secure network" where passwords are concerned

tonij67@xxxxxxxxxxx wrote:

> Just wondering how many others are stuck in this situation:
>
> Admining several systems (mostly solaris boxes) with legacy
> applications that rely on FTP for file transfer. Introduce the concept
> of "security and best practice" (What a concept!) and push for
> replacing said FTP with SSH/SCP/SFTP.
>
Don't forget fsh and fshd--ssh tunnelling software. It can be very handy,
and there's no connection setup-teardown overhead.

> A lot of the response I get to this idea is "whats the big deal? This
> is all on an internal network, so what if we store passwords in plain
> text". Not even my arguments of the simplification of using
> public/private keys would bring to these messy scripts. i.e. relying on
> FTP you need to either use .netrc files or read in authentication
> information. Not to mention the overhead involved when passwords
> change...joy!
>
Been there, done that. One reason might be human nature. At some level,
people don't like to think that there could be Bad Guys amongst the staff.
All the stats about how common insider attacks are, etc., just bounce off
of them. You might actually bring that into the discussion.

Or the network is 100% switched, and they think it can't be sniffed.
Sometimes a demo is impressive enough to change some minds.

Another possibility is that you're being submarined by developers in another
department or something--people who depend on the Berkeley 'r' commands,
and don't want to learn new things or modify scripts. Some training and
coding issues could be a valid point, at least insofar as it's best to know
what pain the organization will incur. Knowing those answers will also tend
to reassure decision makers that you've done your homework.

> Personally, I would never sign off on something like this. But it is
> not always up to me, the best I can do is point out best practice and
> the flaws in this thinking that it's ok to store passwords in plain
> text because "the network is secure" ( and we all know we could debate
> that topic to death)
>
That old chestnut, "the netwok is secure," has a serious fallacy. The only
way that it *can* be secure is if it's encrypted. Otherwise, it can be
sniffed. If they're not worried about that, then they either trust
everyone, or assume that those who are untrustworthy are also incompetent.
An extremely dangerous assumption. And if that's the case, why not just set
null passwords on whatever systems they might find which would still allow
it, and have done?

> So, anyone else out there going through this? Sometimes I feel like I
> am talking to collective blocks of wood...why is there so much
> resistance to moving on from FTP/telnet?

See above. You have my sympathy. If it's any consolation, time is on your
side. Either slowly increasing awareness, or @#$%&! right-now awareness.

Cheers,

Greg
--
Greg Metcalfe
GPG fingerprint: 95B3 2BDD 9152 1E7D A240 37C1 7AE2 9B71 0065 F029
.

Relevant Pages

  • Re: VPN and access rights
    ... What about FTP over SSL? ... that is not secure at all. ... Give him the 'dial in' right that is needed for VPN. ... >> computers within the network! ...
    (microsoft.public.windows.server.sbs)
  • Re: FTP Download Access
    ... >files that are only available via FTP. ... I placed a rule on my firewall that only allows FTP 'GET' traffic ... Is the network still secure? ... Since we don't know that it was secure before you did this, ...
    (microsoft.public.windows.server.security)
  • Best practice vs. "We have a secure network" where passwords are concerned
    ... applications that rely on FTP for file transfer. ... is all on an internal network, so what if we store passwords in plain ...
    (comp.security.unix)
  • Passwords in the registry?
    ... Would it be secure to store passwords in the registry if one only ... stores a cryptographic 1-way hash of the passwords? ...
    (microsoft.public.win2000.registry)