[OpenID] Security related Use Cases?

[Ben Laurie]

On Wed, Oct 22, 2008 at 2:35 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
>
>
>
>
> -----Original Message-----
> From: Ben Laurie [mailto:benl at google.com]
> Sent: Wednesday, October 22, 2008 2:52 AM
> To: Peter Williams
> Cc: Dick Hardt; OpenID List
> Subject: Re: [OpenID] Security related Use Cases?
>
>
>
> On Wed, Oct 22, 2008 at 1:59 AM, Peter Williams <pwilliams at rapattoni.com>
> wrote:
>
>> Built into PC browser? -10
>
>
>
> Why?
>
>
>
>
>
> Eric mentioned the classical reason already. Build it into every new PC
> browser release you like..(like the Microsoft wallet and its support for
> payment-auth protocols? Remember that?) but you have not addressed the
> browser in the 1 billion phones out there, the soap-based active client on
> the corporate desktop, the non visual IE controls embedded in excel scripts,
> and the millions of kiosks. its -10 vs -1 because it perpetuates a myth
> about the omnipotence of the "next browser release".

So you are saying we should not improve the situation ever because we
cannot do it for all platforms simultaneously?

> Developers building the latest browser components don't represent the
> reality of corporate or community deployment. Before one can sign the
> outsourcing contract for 10,000 corporate users to migrate to salesforce.com
> CRM and GoogleApps gmail, the system has work in all the ways that
> Exchange/Novell/Lotus does/did ...with all those devices. In general, that
> means supporting quite a lot of legacy stuff …so critical business process
> don't stop. I have 15% of users sitting at shared PCs, using a shared
> account and shared cookie jar, on a win98-era LAN. (Thus, Yahoo-based
> machine-based auth is out of the question.) If they are lucky, the machine
> is "modern": its running XP home edition, unpatched, with no virus checking.

OK, so you're OK with your users getting phished - that's your problem.

> Developers properly think about tomorrow. Deployers thing about today, and
> the cost of 1000 phone calls while folks struggle to update their drivers,
> migrate their data, revise the BCP (25% annual cost of IT, remember) and
> wonder what happens when their new Google browser cannot work with their
> Apple phone (unlike yesterday, when it all at least worked, albeit painfully
> achieved, with IE). SUN destroyed the public trust with Java, since the
> reality is that change an JVM…and things DO BREAK all the time (contrary to
> the pitch). I was suddenly unable to remotely admin my cisco SSLVPN units
> from my PC, just last week… It cost us 4h incident response time….
>
>
>
>> In "site seal" used at banks, you typically accept/recognize your
>> seal/caption BEFORE you supply password (during signon)!
>
>
>
> So?
>
>
>
> It's the opposite of the assertion in Paul's claim: login first, then get
> the seal. In US current account banking, you typically verify the seal (and
> also get past the anti-fraud expert system) and then login - so as to
> mitigate password phishing and malicious javascript.

Obviously there's no point to confirmation after you gave your
password away (and presumably you'd get the confirmation anyway from a
smart phisher). The point is that studies show that users will still
sign in when the seal is not present.

> The call was for a consistent UI (and UX, whatever that is). SO?, I pointed
> out the first inconsistency case. Paul wants (a), deployed banking wants
> (b).

Paul is wrong, then, if he actually wanted that (I don't think he did).

> The likelihood of deployed banking migrating to future OpenID
> consistent UI doing (a) is somewhere close to zero. They will stay
> consistent with best UI practice, agreed yesterday. If the browser plugin
> enforces Paul's "consistency" vision on good UI, banks will reject that
> browser and go back to their own site design.
>
>
>
> In the medium term, new trends will of course take effect, as they address
> legacy installs. But, its much slower than you ever imagine.
>
>
>
>