Re: [saml-dev] Non-web client authentication

[Andreas Åkre Solberg <Andreas.Solberg@uninett.no>]

Den Mar 6, 2006 kl. 16:58 skrev Scott Cantor:

>> Well, the problem is not bad application and bad user, but good user
>> and bad application. A user should trust the interface in which she
>> enters her credentials. And a user cannot trust a random application.
>
> Then you need OS support (if even that would work), because nothing  
> else
> will give you any additional confidence.
>
> I can't think offhand of anything I enter credentials into today  
> that isn't
> a "random" application apart from when I login to the desktop up  
> front. Of
> course, they're not random in the sense that I installed all of  
> them, but if
> you wanted me to swear on my life that I didn't have a trojan  
> installed, I
> sure wouldn't do it.
>
> I think you're trying to solve an impossible problem, but I'm not  
> sure what
> it has to do with the subject of the thread anyway. It's just as  
> much an
> issue for web authentication as non-web.

OK, I see your point, so let me try argue it from another angle.

As an architecture designer I have problems with designing a system  
where the flow must go through a third party application. If I was an  
IdP I would probably not join the federation if the credentials of my  
users MUST flow through random, third party applications. If they  
went directly to me through a browser window I would be OK with it. Why?

	1) Because if a bad application wants to get the credentials it have  
to make an effort to get them, and directly attack the architecture.  
As an IdP I would say that this is the user's responsibility that  
this do not happen. Bad applications that do open fake web browser  
windows are more likely to be discovered than those that does not. If  
the credential handling is done via third party application, then I  
think the IdP should feel abit responsible for how the application  
handles the credentials. And it is impossible to be responsible for  
unknown code.

	2) One of many goals of federated ID systems is that the user will  
get one single login interface that is visually identical and can be  
trusted. If third party applications should be allowed to display  
username/password widgets, it is a way of saying: "You can enter your  
credentials wherever you see a username/password dialog".

	3) There is alot of good applications that handle credentials bad.  
Some applications cache the password in cleartext to add convenience  
to the user. Say there exists two branches of an open source tool,  
one that caches the password in clear on the disk, and one that  
require the user to enters password every day. Which do you think  
users will select? What is stored in your ~/.subversion/auth/ 
svn.simple/* ?

	4) There is no way (that I know of) to restrict certain applications  
for beeing allowed to perform authentication against the IdP, while  
others are permitted. This means you loose ALL control of third party  
applications performing authentication against your system. I may be  
wrong on this point - please lead me in direction of a good way of  
solving this problem. Since you have no way of restricting what  
applications to authenticate, you have no action to perform if there  
is one or more widespread applications that you know do very bad  
credential handling.

I know we cannot guearantee "real security" when dealing with  
applications on client computers. But, my arguments above still holds.

-- 
Andreas Åkre Solberg
Andreas.Solberg@uninett.no
UNINETT - http://uninett.no

Contact Info and PGP Public Key:
http://andreas.solweb.no/?Account=Work

smime.p7s