KfM 4.0b7: a few questions

Marshall Vale mjv at MIT.EDU
Wed Jan 30 23:07:01 EST 2002

At 9:01 PM -0500 1/30/02, Gavin Eadie wrote:
>... there also some sentiment here at umich that people should 
>obtain their credentials before using an application that needs 
>them. Popping up the dialog as a side effect dulls their sensitivity 
>to typing their password into such a dialog whenever they are asked 
>for it.

This argument has been brought up from time to time and while it 
might make sense in a More Perfect World, in practice I believe it 
creates a bigger burden to the user resulting in higher support 
costs. A classic tradeoff I've heard for security technology is that 
the harder it is to use, the more ways around it users will try to 

Additionally, what I've seen from systems we have deployed here at 
MIT which force users to use a separate application to acquire 
credentials is that they often generates support calls and questions 
due to the often bizarre behaviors or messages that come from 
applications when credentials expire. The sample I'm thinking most 
prominently here is even of a group of people that "should know 
better" too.

Then the argument leads to something like this:
+ Then we should pop up a dialog/print message telling people to use 
application "foo"
- But they don't know where it is or how to use it (an argument even 
presented here on this list recently)
+ Then we should go find it and open it or print out the command for them
- But they might not know what to do next or be confused by the 
various options presented
+ then we should bring up the dialog/issue the command for them.
...and we start the circle again.

As for the argument about people being desensitized, people are 
already used to typing in passwords to anything that ask for them. 
How many of our folks have separate UIs/passwords for the financial 
system, AIM, Yahoo, online banking, database reporting tool, Apple 
developer account, web boards, etc.?

Hey, maybe .Net will get rid of all of those separate password 
dialogs and we will be back down to the one true password dialog :)

>     While I understand the convenience and the past history of doing 
>it this way, I'd like to make a pitch for some discussion of this 
>aspect of things.  I know there's a preference for this feature, 
>maybe it's enough.  What do people think ? ... Gav

It's not really designing a preference here, it's designing a policy 
system. That is an incredibly complex engineering task that when 
confronted with the multitude of other requests, always gets bumped 
off the list. Remember, not every site uses the same privileged 
application or perhaps may even have several of them. How do you 
distribute the policies? How do you make those policies secure? Nasty 
do'ers can still target the policy system to install a trojan 
application and dialog just like now.

Otherwise, you're just annoying the user by forcing them to perform 
unnecessary steps that the computer should be able to automate. And 
isn't that what computers are for?


More information about the krbdev mailing list