Re: Strong authentication for PayPal versus WebPayments

Sent from my iPad

> On 17 May 2014, at 2:32 am, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 
>> 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.

X509v3 subject alternative name really useful to isolate "approved devices" that can seek recovery of those types of Credentials...
> 
> 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 17:29:53 UTC