[unisog] LDAP access for 3rd parties

[Brian Friday]

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:
>> <snip>
>> 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.
>>
> <snip>
>
> 	Then (assuming the data is important enough to generate the required
> level of interest i.e. someone willing to fund it) two factor  
> authentication
> 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  
> was
> 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  
> part
> 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  
> your
> risk manager or internal auditor as well as the person that wants the
> application is often useful.

Totally agree.

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).

- Brian