[Chugalug] Why you don't store passwords, explained

Dan Lyke danlyke at flutterby.com
Tue Nov 5 22:52:09 UTC 2013

On Tue, Nov 5, 2013 at 2:24 PM, Stephen Kraus <ub3ratl4sf00 at gmail.com> wrote:
> Um, correct me if I'm wrong, but a back end for a licensing server for your
> products should have the usernames and passwords associated with the
> keys stored....how else would you associate an account with its users
> data?

So you want to store some identifying information to manage ownership
of the licensing data. Historically, this has been done with a unique
identifier (User Name, email address, something else that's public and
that you can use as a primary key) and a password (secret known only
to the user that can be validated by the server), but there are lots
of things it could be.

For instance, in a perfect world you could imagine that you have a
public/private key pair, and Adobe has a public/private key pair, and
Adobe encrypts a encrypt a random number with their private key and
your public key, sends it to you, you decrypt it with their public key
and your private key, do some manipulation to it, and send it back
encrypted with their public key and your private key.

And this would all be done in the browser behind your back (there are
initiatives in this direction).

But for the password, what I, as a software developer making web sites
that use usernames and passwords want, is a mechanism whereby I can
say "this is the same password that the person with that primary key
gave me last time".

The way you do this is with a hash: You get the password on sign-up,
and the first thing you do is munge it in a way that throws away
information about that password, but in a way that is hard reverse

And the difference between encryption and the hash is that encryption
is reversible. It's not throwing away information.

> And correct me if I'm wrong but if I (Sagan forbid) lose the password
> associated with a very expensive product key, there had better be a
> recovery route.

This is why a password is only one identifier stored with an account.
Other identifiers include email addresses, phone numbers, other
personal data. You don't ever say "here's your old password", you
generate a new password, give it to them via these other identifiers,
say "here's your one-time identifier, use this to change your other

And, really, what you want isn't "user gave me this token so I'm sure
it's the user", it's "user has presented these sets of identifiers
(including, for instance, geolocating IP addresses and saying 'whoah,
that dude doesn't live in Siberia') and we think it's probably the

Identity is hard.


More information about the Chugalug mailing list