Hide presence/absence of users in server (HEXA, SCRAM)

[Hallvard B Furuseth <[e-mail]>]

draft-cridland-sasl-hexa-00.txt.gz and draft-newman-auth-scram-04.txt
describe SASL mechanisms that send the salt from the authcid's server
secret in a challenge.  They need to specify what to send if the authcid
is not found or cannot be authenticated with the mechanism.

Returning a failure immediately would allow clients to use SASL to
discover the presence or indicate the absence of specific authcids in
the server.  I think that'd be wrong, at least for the default behavior.

A fix may be nontrivial though, depending on how seriously one wants to
hide this information.  I guess the fix for the drafts is to just
specify that the mechanism should by default act as if the authcid was
present, and to refer to some other document for the general problem of
faking the existence of users.

Anyone know such a document?  I can only list some quick thoughts on
the subject.  Hopefully someone has written something more thorough:


If you just send a fixed salt for non-existent uses, the client can
compare the salts for several authcids and discover which ones use the
same.  Send a random salt, and one can ask for the same authcid twice
and compare the salts.

Generate the salt from the authcid and a random secret string, and
we are better off - but first the server/protocol must normalize
the authcid.  E.g. if the server looks up SASL users in a case-
insensitive fashion (even when the mechanism says authcids are
case-sensitive), then "john" and "John" must get the same salt.

One could generate "real" salts the same way, in case one could tell
fake from real salts from the algorithm which generates them.

You may want to change the random secret string once in a while, so one
can't notice over time the giveaway that a lot of users don't seem to
ever change their passwords.  That gets messy because a lot of users
would apparently change their password (and salt) at the same time,
which would also giveaway.  So... generate the supposed time of password
change from authcid and one secret random string, and use that to select
from a set of other secret random strings which is used to generate the
salt..


By now I'm far beyond what makes sense to say in a mechanism spec
though.  Which is why a reference to another document makes more sense.

After all it may be trivially easy to discover the existence of a user
in any case, e.g. if the users can be found with 'ypcat passwd' on Unix
or can be looked up via the protocol.

Also one can often discover the presence/absence of users in other
ways, even if the protocol's way of hiding users is to pretend they
are not there.  E.g. take the time of protocol requests (auth or other
operations) involving the user.

-- 
Regards,
Hallvard