search

iriscouch / browserid_couchdb

Mozilla BrowserID support plugin for CouchDB
Apache License 2.0
57 stars 9 forks source link

Add option to hash BrowserID usernames #5

Open gertcuykens opened 13 years ago

gertcuykens commented 13 years ago

If you hash the name how can you know which one you need to assign other roles too?

{ "type": "user", "name": "22sda98s7das9t9t6a9sd6atsd9t97asdt7", "roles": ["browserid","admin"], "salt": "1d57abebf2c94fb0a851dad9ae372ea2", "browserid": true }

is it not better to just make _users not accessible

jhs commented 13 years ago

I think there are workarounds for all of this; however, ultimately the only solution IMO is to make _users inaccessible. I have not confirmed, but I believe there might also be problems with couches sharing subsets of each others' users databases. If I trust you and you trust me, then I should be able to replicate down all of your users docs from e.g. the @example.com domain. If the hash is based on a per-server salt, then document IDs will not be identical, and so that won't work.

Closing off the _users db works really well with this plugin. CouchDB will open the _users database (as an admin) for two reasons:

  1. When you try to authenticate, it will check against your doc
  2. When you create a BrowserID account

The major reason to leave _users open is for account creation, and BrowserID obviates that.

Even account creation can occur with a private _users database, if I can get my inbox db patch merged into Apache CouchDB: https://issues.apache.org/jira/browse/COUCHDB-1287 then people can still drop new accounts in the DB but not read them back, and thus not be able to enumerate users and email addresses on the system.