Add option to hash BrowserID usernames

[thedod]

If there's a config option in the browserid called hash_secret, usernames become a hash of the BrowserID email, with hash_secret as salt. If hash_secret doesn't exist - it works just like before (username is the BrowserID email address).

[jhs]

Looks good. I'll roll this into an Iris Couch update ASAP, because the example app has also stopped working as you pointed out.

@maxogden warned me against making an example implementation at all. Almost everything in /_browserid is unnecessary. Maybe he was right after all.

[BigBlueHat]

Out of curiosity why wasn't something like sha1sum used for encrypting the email addresses? It's good enough for FOAF:
http://xmlns.com/foaf/spec/#term_mbox_sha1sum

That would solve the disclosure problem without making hashes that are dependent on each CouchDB instances salt.

Thoughts?

[jhs]

Actually I think that is a serious problem. It breaks the replication model for CouchDB. We should be able to replicate _users databases with each other (if we trust each other) but this change makes that problematic.

@thedod, what do you think? Is there a way to balance email address privacy with the ability to get a deterministic "username" value?

[thedod]

Plain unseeded Sha1sum has the gravatar vulnerability: if you have a guess, it's simple and computationally cheap to verify (even without rainbow tables).

It's not necessarily a problem when _users can't be replicated. In some situations it can even be an advantage: For example you can open two browser tabs at mingle1 and mingle2 (with the same BrowserID credentials) and join the same conversations as two different identities.

If you have some other app where you do want consistency across servers (and maybe even the ability to sync _users), the best way to achieve this would be by implementing an OpenID plugin, and there are many reasons to do so anyway (e.g. blackout resilience).

Server-specific BrowserID hashing started as a compromise out of necessity (the mix between CouchApp's total transparency and BrowserID's choice of email as id is a privacy hazard otherwise). However - the side effect of "the unbearable lightness of trolling" turns out to be a promising feature [IMHO].

If/when I start working on the OpenID plugin, I believe I'll add an option to hash the id (although OpenID doesn't really require this): it's hell for data miners, and for some applications - this is a blessing ;)

[jhs]

Those are all excellent points.

Is the following statement true?

If users trust each other with a common _users database, then they
trust each other with a common salt.

I wonder if we could exploit that. Somehow copy the salt value (and
while I'm at it, maybe a version of the implementation, for when we
switch to SHA256 or whatever).

Another thought is that each application has different needs. It might
be acceptable for some applications to use no salt (or at least a
hard-coded salt, so you can't yet just google the sha1 sums, at least
until couch becomes ubiquitous).

But I think you are right, BrowserID is optimized for applications
where people participate mostly using their real names.

On Wed, Dec 7, 2011 at 1:50 AM, Nimrod S. Kerrett
reply@reply.github.com
wrote:

Plain unseeded Sha1sum has the gravatar vulnerability: if you have a guess, it's simple and computationally cheap to verify (even without rainbow tables).

It's not necessarily a problem when _users can't be replicated. In some situations it can even be an advantage: For example you can open two browser tabs at mingle1 and mingle2 (with the same BrowserID credentials) and join the same conversations as two different identities.

If you have some other app where you do want consistency across servers (and maybe even the ability to sync _users), the best way to achieve this would be by implementing an OpenID plugin, and there are many reasons to do so anyway (e.g. blackout resilience).

Server-specific BrowserID hashing started as a compromise out of necessity (the mix between CouchApp's total transparency and BrowserID's choice of email as id is a privacy hazard otherwise). However - the side effect of "the unbearable lightness of trolling" turns out to be a promising feature [IMHO].

If/when I start working on the OpenID plugin, I believe I'll add an option to hash the id (although OpenID doesn't really require this): it's hell for data miners, and for some applications - this is a blessing ;)

---

Reply to this email directly or view it on GitHub:
#2 (comment)

Iris Couch

[BigBlueHat]

Been pondering all this for a bit. First, it's a great discussion and
I'm glad it's finally being had in the "couch world." Second, I think
there's a number of topics here that are all intermingled and would
likely best be solved by a buffet of configuration options. :)

I would like to continue this conversation further (as we do have a
tangle of ideas and options on the table, and I'm afraid we may miss the
forest...), so what do you two think about moving this discussion to the
CouchDB mailing list?

BrowserID's long term goal (afaik) is to have e-mail providers do the
e-mail verifications. If you wanted a layer of privacy on top of that,
you'd need to use the Gravatar "hack" demoed above by TheDod. BrowserID
seems to punt on anonymity leaving that to the address owner (i.e., if I
don't want you to connect my activities between two sites, I shouldn't
use the same e-mail address to log into them).

At any rate, I do think another venue is better, and I am very
interested in knowing more about why OpenID is a better solution than
BrowserID from a privacy as well as security perspective.

Thanks again for kicking this off, TheDod. See you both 'round the
Interwebz.

[thedod]

BrowserID seems to punt on anonymity leaving that to the address owner (i.e., if I don't want you to connect my activities between two sites, I shouldn't use the same e-mail address to log into them).

It wouldn't work (unless the end user is tricky). BrowserID, as a single-sign-on (SSO) service won't let you be logged in at the same time as different ids (email addresses) in different browser tabs.

OpenID is an SSO too, but there are many providers, so I can have an SSO environment as gay, another one as a cancer patient, etc.

If I understand correctly, even in the future (when BrowserID plans to allow for non-mozilla identity providers), an end user has a single identity [at least simultaneously] all over the BrowserID world. The way I see it, this violates tho basic human right to troll :)

I would like to continue this conversation further (as we do have a tangle of ideas and options on the table, and I'm afraid we may miss the forest...), so what do you two think about moving this discussion to the CouchDB mailing list?

Maybe I'll join it mid January (traveling at the moment and don't want to bum-rush my mailbox).

If you feel like raising the identity issue at the mailing list before I'm back, I've written some text about it, and people are welcome to contact me via github messaging or here.

Maybe we can try and discuss this via mingle itself ;)