On Tue, 23 May 2000, Ng, Kenneth (US) wrote:
> PcAnywhere 9.0.0 set to its default security value uses a
> trivial encryption method so user names and password are
> not sent directly in clear. Since most users have the
> encryption methods set to either "none" or "PcAnyWhere",
> their password are sent with weak encryption.
Note, the default *isn't* the only option (which was implied by your
original post.) While my opinion on Symantec shipping the default crappy
pseudo-protection as it is are probably obvious, since the CryptoAPI
stuff requires non-international versions of NT to do it right, I can
understand where the decision point was.
Let's face it, anyone who's putting an NT server on the Net who doesn't
put the effort into clicking on the secure PCAnywhere option is probably
going to have significantly bigger issues.
> > has been cracked. I am the security administrator for our LAN and a user
> > wants to use it on our network. Is there any documentation on this topic
> or
> > a site that has made the claim of cracking it? I just don't want to trust
> a
> > company that says their security is solid (there is a shocker)when it
> infact
> > isn't. Any information or URL's that can point me in the right direction?
If the user has half a clue, they'll simply counter that they're prepared
to do the full public key/symetric cipher option, which leaves the
security admin trying to find yet another reason to disallow it.
It's better to have those arguments lined up *first* than to go to a
meeting prepared to squash something and find that the other side has an
effective counter argument to your major issue.
If your security policy doesn't already encompass what protocols will and
won't be allowed as well as a complete review process and decision chain
for exceptions to that policy you're fighting this from the wrong end, and
you're liekly to be going around the same circle for each
product/protocol/server/project/luser.
If you included formal luser security training before being able to admin
external servers in the policy, it'd probably nix a good number of "amost
clued" as well as help the overall organizational posture. If it's the
other way around, and the luser wants access to the internal network and
your policy doesn't prohibit it explicitly, you've got a lot of work to
do.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
