- From: Dave Raggett <dsr@w3.org>
- Date: Fri, 16 May 2014 10:33:14 +0100
- To: public-webpayments@w3.org
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. 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. 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. 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? I would also like to see an analysis of the potential for replay attacks. 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. -- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Friday, 16 May 2014 09:33:45 UTC