[Cryptography] password fatigue; was: Lastpass

[Phill]

> On Jun 16, 2015, at 10:37 PM, John Denker <jsd at av8n.com> wrote:
> 
> On 06/16/2015 04:19 PM, Randy Bush wrote:
> 
>> do not store critical secrets on others' systems.  period.  then, learn
>> how to secure your own system(s); this is seriousy hard.
> 
> There are several ideas there.  My comments:


> 2) Password fatigue is a problem.  We need to focus
> on this.  Lastpass gets "some" brownie points for
> attempting to solve the problem, even if you think 
> their attempt is less than 100% elegant and/or
> less than 100% successful.

I consider the cost of remembering a password to be $100 each. So unless the asset being secured belongs to me and is worth more than $100, I use the same password.

If the site requires capitals and a number: Useless1



> 3a) Snickering at lastpass does not solve the problem,
> not even a little bit.
> 
> 3b) Telling users to solve the problem on their own
> does not solve the problem.
> 
> 3c) The only way I can see to solve the password fatigue
> problem is to get web services to stop asking for a
> per-site password and instead use some sort of zero-
> knowledge authentication.  Schemes for doing this have
> been known for a long time.
>   https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
> 
> 3d) If anybody knows of a better solution, please let 
> us know.

I don’t see a real need for zero knowledge. That might be nice to have but public key is OK. All that matters is that the authentication process does not disclose the authentication credential.

But to be useful, a system has to do more than allow passwords to be replaced, it has to service the user’s need to remember all the stupid passwords. Here is where I think we have been going wrong, we have seen these as alternatives:

1) A password management system for storing passwords in the cloud
2) A public key based auth scheme that eliminates the need for passwords.

Any system that gets adopted by users has to be both.


As part of my prismproof project I have been writing a service to manage private keys. I want these to be very easy to use, completely transparent. Which forces me to use a cloud service. But I am not forced to use a trusted service. In fact the degree of trust in the service is very limited. The service never gets any confidential data, all the data is encrypted. 

It occurs to me that I can use exactly the same infrastructure for passwords as for private keys.


The basic idea is as follows:

0) The user never needs to be an expert.

1) Every device has its own private keys, every independent purpose (authentication, code signing, encryption, etc) gets its own keys. Unless these are email decryption keys, they are per-device.

2) Each user has a personal virtual network consisting of the devices they own. Devices can be added or removed at any time. To add a device, the user tells it which personal network to join, a join request appears on their authorized admin devices, they approve it. 

3) Recovery is supported through a master key signing key and an encryption escrow key. By default, each time an encryption keypair is created, the decryption key is escrowed.


A number of keys have to be migrated from one device to another. In particular, end to end email encryption is only practical if the user can share their decryption key on all the machines they read email on. 

[Right now I am moving the key itself, when we move to ECC based algorithms it becomes possible for split key schemes to be employed. One half of the key residing at a quasi trusted service, the other on the device that reads the mail.]

So to address this use case, I store the encrypted private key in the cloud and upload decryption blobs for every device that is authorized to access it. 


This same structure can be used to store passwords. When I tell my browser to remember a password, it encrypts it under the set of keys for the currently authorized devices. When a browser needs to access a site, it decrypts the username/password combo for that site.

This provides the same convenience as lastpass without the need to trust the service. There is even a mechanism that bounds the ability of the service to perform a DoS attack - the encrypted blobs are shared across a surface of independent providers and a blockchain type mechanism used to prevent default. 

If sites prefer to abandon the username/password combo, the same infrastructure supports public key based authentication. However this may not be essential if we can get the scheme widely supported since if a user can guarantee that their username/password will be accessible from every site they use, they can use a randomly generated password with a very high work factor comparable to a 128 bit key as there is no need to remember it.