Re: Strong authentication for PayPal versus WebPayments

On 05/16/2014 05:33 AM, Dave Raggett wrote:
> 
> On 15/05/14 23:34, Dave Longley wrote:
>> On 05/15/2014 05:18 PM, Manu Sporny wrote:
>>> How it Works
>>> ------------
>>>
>>> Here's what the Open Credentials login process looks like (right now,
>>> it's still under development):
>>>
>>> 1. Website provides a "Sign In" button.
>>> 2. The browser displays a pop-up login screen on a login mixnet
>>>     requesting email + passphrase. This step can be done in the
>>>     same way that Persona did it - a shim that doesn't require any
>>>     browser buy-in in the beginning. The login mixnet is required
>>>     to ensure that your identity provider can't track which sites
>>>     you're logging in to and sending your private information to.
>>> 3. The user types in their email and passphrase. A hash is created
>>>     from the email and passphrase and a query is sent to a
>>>     Telehash network (DHT-based decentralized network). All identity
>>>     providers are connected to this network, and your one is looking out
>>>     for a particular query matching the hash you generated. Once it
>>>     detects it, your identity provider responds with an encrypted
>>>     chunk that is then decrypted using the passphrase.
>>> 4. The decrypted chunk contains a private key that can then be used
>>>     to counter-sign data sent from the identity provider.
>> Note that the design may change so that this "login" private key may
>> instead be stored using WebCrypto/LocalStorage via your IdP. This would
>> mean that the only information stored in the encrypted data returned via
>> Telehash would be the URL to your IdP. This may help protect against
>> phishing and other attacks, etc.
>>
>>
> 
> Just to check my understanding ...
> 
> The approach as described above will encourage phishing since if you can
> fool someone into typing their email address and passphrase on your
> spoofed site, you can subsequently pose as them to gain access to their
> account.

Yes, the original description where the private key can be accessed by
fooling someone into giving up their email address and passphrase would
allow an attacker to gain access to their account. We want to mitigate
that by reducing what information is available should a phishing attack
be successful.


> This can be made harder if when the account is set up, a key
> is provided by the identity provider in the encrypted chunk, and stored
> via WebCrypto/LocalStorage, and used in subsequent authentications as a
> hidden key as evidence that the user is logging in from the original
> device.

Yes, this is very close to what I was describing. I don't think there's
a need to have the key be included in any encrypted chunk (unless you're
just talking about TLS); when you visit your identity provider you can
"register a new device" with them that will allow you to do login at a
later time with that device. The act of registration is otherwise as you
described -- a private key is stored via WebCrypto/LocalStorage and is
only accessible via the IdP's domain. This private key can later be
accessed, for example, via an iframe during the login process (to some
other relying party).

This way devices can only login if they have been previously authorized
at the identity provider. Furthermore, the key that provides this
protection is only accessible if it's on the device that is performing
the login. Stealing the user's email address and passphrase will not get
you access to that key and you can't later pose as that user to gain
access to the account.


> This could be a simple matter of appending the hidden key to
> the string formed by the concatenation of the email address and
> passphrase.   Another refinement would be the addition of a nonce.

This step may be unnecessary. The steps may simply be:

1. User enters email address and passphrase, which are concatenated and
sent as a Telehash request to obtain an encrypted blob from the identity
provider that is a node on the Telehash network.

2. When a response is received, the passphrase is used to decrypt the
chunk and get the IdP URL. The IdP URL is accessed via an iframe (for
example) which uses the previously registered private key from
WebCrypto/LocalStorage for authorization.

> If an attacker has fooled users into disclosing their email address and
> passphrase, how does the identity provider differentiate the attacker
> from users trying to login from a new device?

The email address and passphrase are not used (or are insufficient) to
log into the Identity Provider. A separate password (or similar secret)
must be used. An attacker must also be able to masquerade as the
identity provider itself and steal this information (as is the case
today for logging in via Google, Facebook, etc.). Various forms of
N-factor authentication could be required by the identity provider in
order to register a new device. This doesn't have to be part of the
standard itself, but is value add for an IdP.

> I would also like to see an analysis of the potential for replay attacks.

Not all replay attacks here would be dangerous, but here's an example of
one that would be that has been considered: suppose a relying party were
to take an authenticated credential and attempt to use it to login as
the user on another site. In order to prevent this, the protocol
requires that the domain be included in the signed data.

To clarify:

1. The domain the user wants to provide a credential to is included in
the information given to the identity provider so that the user can
authorize it. It can then be included when the identity provider
counter-signs the credential. Note that, in order to protect the user's
privacy, the domain, at this point, could be obscured by the login
mixnet. The counter-signed credential is then given to the login mixnet.

2. The login mixnet may then display the actual domain to the user and,
at this point, the user's private key (from local storage) also
counter-signs the credential. Note that this process will prevent the
identity provider from knowing where the user is sending their
credentials, thereby protecting their privacy, however, it may introduce
a further (behind the scenes) step for sharing device private keys with
the login mixnet domain. There are more details here that have been
discussed and can be further ironed out. I'm just noting that there are
a number of important privacy goals here to be met with this design.

3. The authorized credential is then sent to the relying party which
must check to ensure that the appropriate domain was included w/the
signed data.

There are some more details in the protocol related to privacy, such as
requiring the IdP to sign and include, with the authorized credential,
the user public key associated with the device they are logging in with.
This would prevent the IdP from detecting where users are logging in by
monitoring requests for public keys that follow requests for
credentials. But, as Manu said in his email, this particular email
thread is just an overview of the high-level idea for how these parts
can come together to meet the goals outlined.

> Pop-ups can be a problem depending upon your device and browser
> settings.  Presumably, an IFRAME element would do instead and has the
> benefit of executing in a different security sandbox.

Note that I think the term "pop-ups" may refer to opening a new window
as the result of a user click, which typically works just fine. But,
yes, IFRAMEs may also be used. There are advantages/disadvantages to
both, such as the fact that a new window may more clearly indicate
various security/trust information via the URL bar, etc.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Friday, 16 May 2014 16:33:01 UTC