[unisog] LDAP access for 3rd parties
bfriday at lasierra.edu
Thu Feb 14 02:03:15 GMT 2008
On Feb 13, 2008, at 10:58 AM, Peter Van Epp wrote:
> On Wed, Feb 13, 2008 at 01:15:45PM -0500, Oscar Knight wrote:
>> All it would take is a line or two of code at the 3rd party site to
>> store the username/password. I'm not accusing 3rd parties of
>> intentional malice, just pointing out the risk.
> Then (assuming the data is important enough to generate the required
> level of interest i.e. someone willing to fund it) two factor
> is what you want. The remote site doesn't get passwords at all only an
> encrypted one time authentication (skey or opie will do this for
> free and
> without dongles at the cost of administrative process and user
> education). You
> are correct any remote authentication which requires the user to
> provide a
> reusable password is potentially compromisable but that should have
> been part
> of the risk assessment that happened when access to that application
> signed off on by the appropriate authorities. I'd also note I'd be a
> lot more
> concerned about the user's own machine (assuming you don't have
> locked down
> desktops) than a vendor application although a lot of them are
> pretty bad too.
> The bottom line is reusable passwords are just plain evil, the
> problem is the
> cost of the alternatives.
> Your only point of potential fault would be in not pointing this
> possibility out to the people making the decision to grant access as
> of the risk assessment. At least here, the security tail can't wag the
> university dog, we can only point out the risks although doing so to
> risk manager or internal auditor as well as the person that wants the
> application is often useful.
If you do not have a trust relationship with the vendor then make sure
you have a security "it is your fault for being stupid" clause in. Or
the option is always available to not use their software. Though
getting faculty/staff buy in that they can not use the latest "cool
device/service etc" tends to be problematic, specially for those "my
gadget is cooler than your gadget" folks. This also assumes you will
control what you deploy, how you deploy it, who you deploy it with and
that everyone will be happy with your decision.
Until and when every single risk factor is known by all parties
negotiating the contracts and assuming vendors decide it is better to
be forthright about their security. Stupid contracts will be signed
committing IT resources/personnel to securing and integrating software
with wildly varying degrees of security.
It is never more appalling to walk into a meeting knowing a contract
has been signed for a product which upon a mild interrogation is shown
to be using the awesome power of HTTP security and unencrypted cookies
on a device which accepts a minimum username of one character (case
insensitive) and a one character password (no symbols please).
More information about the unisog