[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] Non-web client authentication
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]