[Freeipa-users] Ipsilon and WebAthena

[Simo Sorce]

On Wed, 2014-06-18 at 17:40 +0000, Nordgren, Bryce L -FS wrote:
> > Where does the javascript come from ?
> > How do you trust it is not going to send your password somewhere ?
> > How do you trust another bug in the browser will not allow another "tab"
> > top read the memory of the browser including your password or TGT ?
> >
> > There is a good reason crypto and keys on one side and javascript on the
> > other should not come in contact, IMO.
> 
> Clearly there are potential problems. The question is, are they bigger
> problems than sending your password across the net?

No, but why should you ?
It is quite simple to just call gssapi_acquire_cred_with_password(), it
would require only a simple change in the browser to show you a prompt
like it is done with Basic Auth, and then you are future proof and use
the system cred store.

>  The first two questions are not specific to javascript, you should
> have the same concerns with any web password prompt, particularly
> those technologies which redirect browsers all over the internet. The
> last one is common to any session token you might have after
> authenticating. These are all high-visibility, well exercised regions
> of code which should get fixed quickly when a problem is detected.

It's all easy except when it is not :-)

> How do you know openssl doesn't have another heartbleed bug in it?

I don't but at least I know exactly when it changes and what version it
is running. How do you know if the thing showing you a prompt is valid ?
how do you know it is not a hidden frame trying to steal your
credentials ? How do you know it is an up to date version with fixed
vulnerabilities ?

Although poorly implemented today, at least Basic Auth could be built so
that a trusted path is used and a properly trained user could not be
induced to give their credentials to an impostor fake dialog in a
website.

> Relevant question are: Given that a http basic auth challenge and the
> Kerberos javascript both would be protected/authenticated by the same
> SSL connection, is there a benefit to sending Kerberos exchanges
> instead of your password?

There may be some advantages but I see a lot of downsides too.

> Would implementing this strategy help reduce the number of websites
> which require their own user database, reducing user's exposure to
> ill-managed systems?

Probably not.

>  (and if we assume they use the same password in more than one place:
> reduce the system manager's exposure to having someone else's
> compromised system plague my machines?)

I think that if these are your concerns it would be more effective to
use OTPs where possible.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York