Re: Proof of Concept: Identity Credentials Login

On 06/11/2014 02:35 PM, Evan Schwartz wrote:
> Does the security of the data users store in the to-be-decentralized
> database depend entirely on them choosing a random 20+ character
> password?

Yes, however, "the data" is merely a mapping to their identity provider,
nothing else. So if that password is compromised, an attacker only
learns that someone with a particular email address has used a
particular identity provider at some point. They do not get any access
to their credentials.

A user's IdP will determine how their credentials are stored and what
security measures to put in place to protect the security of those
credentials. An IdP can do whatever it wants in that space to attract
users to its service.


> Given what we learned about passwords from the Adobe leak, it
> seems like we can't wholly rely on people choosing secure passwords
> (according to this list
> <http://stricture-group.com/files/adobe-top100.txt> "123456" was the
> password chosen by 1,911,938 Adobe users). It would be trivial to break
> most peoples' email/password combinations, especially if
> decentralization meant that attackers could mount offline attacks on the
> whole database. I'd also guess that using email as the main identifier
> also increases the likelihood that people use the same password in the
> identity credentials system they use for their actual email account. A
> while ago, Stefan Thomas, CTO at Ripple Labs, wrote up this paper
> <http://justmoon.github.io/pakdf/> about using a "Peer-Assisted Key
> Derivation Function" (PAKDF) to address this type of problem, which
> might be of interest here.

Ideas regarding more secure, alternative mechanisms for generating
queries/storing email => IdP mappings are of course welcome. I just want
to clarify that this piece of the Identity Credentials login mechanism
is essentially a shim; the long term goal is to have browsers/devices
remember these mappings for users. A browser/device has free reign to
determine the details for how those mappings are stored/retrieved.


> Am I correct in thinking that the plan for what would be integrated into
> the browser would just be a token that allows you to skip some
> additional authentication step, as opposed to the credentials
> themselves?

Yes. Though, there's nothing in this approach that limits a browser
manufacturer from also functioning as an IdP. An IdP is responsible for
indicating how your credentials are stored. That will usually mean the
IdP performs the storage itself, but it could use some 3rd party
mechanism to store them.


> I hear browsers mentioned quite often as the ideal storage
> platform for secure information but I always wonder what happens if I
> lose or switch my computer, have multiple devices, or if my internet
> access is limited to internet cafes.

I think it's reasonable to expect that many people will choose IdPs that
store their your credentials in way that will be accessible to them
through a variety of devices. Again, I don't think the Identity
Credentials spec needs to mandate the storage mechanism, it only needs
to indicate that credentials should be available on an as needed basis.


> 
>     When you click “Login”, your email address
>        and passphrase are SHA-256′d and sent as a query to the Telehash
>        network.
> 
> 
> Won't this hash be publicly available in the distributed hash table?
> What exactly is stored in the blob in the Telehash network? Is it just
> which identity provider I'm using?

Yes, it's publicly available -- as in, if you can guess a hash, then you
can find its associated encrypted blob. Yes, the email => IdP mapping is
what is stored.


> 
>     Your identity provider will receive the request and
>        respond to the query with an encrypted message that will then be
>        decrypted using your passphrase.
> 
> 
> Does that mean my identity provider has my plaintext passphrase?

No, the decryption of the encrypted message is performed by the login
mixnet ("login-hub.com" in the demo). This is the only site that knows
your plaintext passphrase. The passphrase used to encrypt your email =>
IdP mapping can and should be different from any used with your IdP.
Your IdP can use whatever login mechanism they want to -- which may also
happen to use email+passphrase.


> 
>     The contents of that message will
>        tell the login hub where your identity provider is holding your
>        identity. The request for the email credential is then forwarded
>        to your identity provider.
> 
> 
> How will the request to this identity provider location/URL be
> authenticated?

My understanding is that this is entirely up to the IdP. Currently,
during the login process, once the IdP URL has been retrieved, the user
agent is redirected to the Identity Provider for authentication and
authorization to send credentials to the relying party. The demo uses
email + password (IIRC) for authentication.


> 
> -- 
> Evan Schwartz
> Developer + Technology Pioneer
> Ripple Labs Inc.
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 11 June 2014 20:58:42 UTC