First of all, let's point out that you CAN enable sync of an auth db if you want to.
The passwords in a Zumero internal auth db are encrypted with bcrypt. If you pull the auth db down to a mobile device, you do introduce a security risk, because now someone can crack things open, get the encrypted passwords, and try to decrypt them. But the additional risk isn't huge. The passwords are still encrypted.
To enable an internal auth dbfile to be pulled, you need to do two things:
When you create it (with zumero_internal_auth_create), you must specify the last two arguments of the function to describe who is allowed to add ACL entries. For example, to allow members of zumero_users_admin to alter the ACL entries on an auth db, do something like this:
SELECT zumero_internal_auth_create( server_url, dbfile, credentials_scheme, credentials_username, credentials_password, first_username, first_password, allow_add_scheme, allow_add_who, zumero_internal_auth_scheme('zumero_users_admin'), zumero_named_constant('acl_who_any_authenticated_user') );
Use zumero_internal_auth_set_acl_entry to add the ability to pull:
SELECT zumero_internal_auth_set_acl_entry( server_url, dbfile, credentials_scheme, credentials_user, credentials_password, scheme, who, tbl, zumero_named_constant('acl_op_pull'), zumero_named_constant('acl_result_allow'), );
Note that you can restrict WHO is allowed to pull. Note also that granting the ability to pull an auth db does not grant any ability to modify it in other ways.
OK, back to the question:
Another option is to have two internal auth dbs, one with passwords, and one which has nothing but aliases into the other one. Now you can enable sync on the one with the aliases, thus allowing your mobile app to have a list of users without having access to the passwords.
Cracking a bcrypt string is hard, but it's even harder if you don't have the string. :-)
To set things up this way, you'll need to use zumero_internal_auth_create() to create TWO auth dbs. And each time you add a user, you'll need to add it twice. Once in the passwords db with zumero_internal_auth_add_user(), and once in the aliases db with zumero_internal_auth_add_alias().
SELECT zumero_internal_auth_create(
server_url,
'passwords',
credentials_scheme,
credentials_username,
credentials_password,
first_username,
first_password,
zumero_internal_auth_scheme('zumero_users_admin'),
zumero_named_constant('acl_who_any_authenticated_user'),
zumero_internal_auth_scheme('zumero_users_admin'),
zumero_named_constant('acl_who_any_authenticated_user')
);
SELECT zumero_internal_auth_create(
server_url,
'aliases',
credentials_scheme,
credentials_username,
credentials_password,
first_username,
first_password,
zumero_internal_auth_scheme('zumero_users_admin'),
zumero_named_constant('acl_who_any_authenticated_user'),
zumero_internal_auth_scheme('zumero_users_admin'),
zumero_named_constant('acl_who_any_authenticated_user')
);
SELECT zumero_internal_auth_set_acl_entry(
server_url,
'aliases',
credentials_scheme,
credentials_user,
credentials_password,
scheme,
who,
tbl,
zumero_named_constant('acl_op_pull'),
zumero_named_constant('acl_result_allow'),
);
SELECT zumero_internal_auth_add_user(
server_url,
'passwords',
credentials_scheme,
credentials_username,
credentials_password,
'gandalf',
'thegrey'
);
SELECT zumero_internal_auth_add_alias(
server_url,
'aliases',
credentials_scheme,
credentials_username,
credentials_password,
'gandalf',
'passwords',
'gandalf'
);