Assurance Enhancements for IdPv2

[Cantor, Scott]

On 5/21/13 5:05 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>Are you saying a solution that is difficult to deploy is probably
>gonna get deployed incorrectly? Of course that's true. It's even true
>of passwords alone.

It's more true when you go beyond passwords though, and especially when
you try and make security "better" by combining unrelated things into
something you think is stronger. Security doesn't always work like that.

>Incomplete in what way? Do you mean there's a higher probability the
>solution is deployed incorrectly? Maybe. Otoh, a solution that
>utilizes two independent channels is usually preferred to one that
>doesn't, so it cuts both ways.

Having independent channels isn't always better, but even when it is, that
doesn't necessarily mean that the deployment has to expose the channels as
two different components that have to be combined by the deployer. It can
look like a single thing if it's provided as a single solution, and
something like an IdP should be able to interface with it without knowing
about all that complexity.

>I'm not sure I understand the point you're trying to make. You seem to
>be saying that some people deploy OATH incorrectly (which is true) but
>I can't be sure. You're not saying that deploying OATH as a second
>factor on top of an existing password-based authentication system is
>inherently flawed, are you?

In that it requires deployers to do the right things to make the
combination work correctly, I think it's suboptimal, yes.

-- Scott