[Cryptography] Cost of remembering a password

Rob Meijer pibara at gmail.com
Mon Aug 18 02:42:10 EDT 2014


2014-08-16 13:38 GMT+02:00 Michael Kjörling <michael at kjorling.se>:

Then, ideally, when I view a sign-up form that asks for a password,
> the password field would have some sort of visible indication next to
> it that allows me to automatically generate and store a secure
> password for that particular web site. If there is no obvious
> connection between the sign-up and login forms, in the login form I'd
> be able to pick something along the lines of "for this site
> (login.example.com), use the credentials previously used on
> signup.example.com", perhaps offering by default the FQDNs for which
> there are stored passwords which fall under the same second-level
> domain (with handling of those top-level domains which use an
> intermediate label to separate types of sites, as is the case for e.g.
> .uk, .nz, and a handful of others).
>
> A login form that currently looks like (Unicode and monospace font
> needed for these mockups to look reasonable):
>
>     Username: [my-username          ]
>     Password: [•••••••••••••••      ]
>               [ ✔ Sign in ]
>
> could thus look a bit like the following, with the menu expanded:
>
>     Username: [my-username          ]
>     Password: [•••••••••••••••      ][⚙]
>               [ ✔ Sign in ]            ⬉
>                                        | Use the password from
> signup.example.com |
>                                        | Use the password from
> www.example.com    |
>
>  |------------------------------------------|
>                                        | Select among stored passwords...
>        |
>                                        | Generate a new password...
>        |
>                                        | Forget password on
> login.example.com...  |
>
>  `------------------------------------------'
>
> If that could be solved in a way that makes it easy to use even for
> novices, and perhaps even allowing integration with an external
> password manager for advanced users, I think we would already be _far_
> along the way toward at least encouraging people to use _different_
> passwords everywhere. And that, in itself, besides not requiring a
> total revamp of lots of sites' authentication logic, would be a huge
> win in practice.
>

​Instead of storing passwords on a per-site basis, what about a poor-mans
hash-based hierarchy:

psk=​PBKDF2(secret, "www.example.com", i, n)
q3key=PBKDF2(psk,​PBKDF2(shared,"2014-q3", i, n)
password = BASE32(​PBKDF2(q3key,"login", i, n))

Such a hierarchy could be the first step to more fine-grained authorization
tokens. Fine-grained authorization tokens that could help in avoiding the
problems with using credentials as means of delegation between people.

contactskey =  ​PBKDF2(q3key,"contacts", i, n)​
readonlycontactskey = ​PBKDF2(contactskey,"read-only", i, n)
supplierscontactinfocap = BASE32(PBKDF2(readonlycontactskey,"suppliers", i,
n))

So instead of: "Here are the credentials for my account, could you please
contact all product X suppliers for a quote on a quantity of Y of product
X", you would get: "Here is a sparsecap with the contact info for all our
suppliers, could you please contact all product X suppliers for a quote on
a quantity of Y of product X"

If browser plugin and site builders could agree on such a scheme, you would
have an amazing way to gain more usable security in the sense that you can
promote delegation that with passwords currently is discouraged out of
security considerations. So you either get considerably more work done with
a negligible decrease in security or, and this is likely more common, you
get significantly more security by not conflating delegation and abdication
as happens when you share regular passwords.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140818/5cd3b182/attachment.html>


More information about the cryptography mailing list