Subject: Re: Hide presence/absence of users in server (HEXA, SCRAM)
From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Date: Mon, 30 Apr 2007 21:05:49 +0200
List-Id: <ietf-sasl.imc.org>

I wrote:
> Generate the salt from the authcid and a random secret string, and
> we are better off -
> (...)
> One could generate "real" salts the same way, in case one could tell
> fake from real salts from the algorithm which generates them.

...and then if it is possible to tell the difference, "real" salts get
less than random and thus an attack on a real user easier.  Not my
brightest idea.

-- 
Regards,
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Hide presence/absence of users in server (HEXA, SCRAM)
Date: Mon, 30 Apr 2007 17:42:33 +0200
Sender: [email-masked]

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

From: [email-masked]
Subject: Please confirm your message
Reply-To: [email-masked]
Date: Fri, 27 Apr 2007 11:17:42 -0400
To: [email-masked]
Auto-Submitted: auto-replied
Sender: [email-masked]

--===============0860186178==
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Description: Confirmation Request
Content-Disposition: inline

This message was created automatically by mail delivery software (TMDA).

Your message attached below is being held because the address
<[email-masked]> has not been verified.

To release your message for delivery, please send an empty message
to the following address, or use your mailer's "Reply" feature.

   [email-masked]

This confirmation verifies that your message is legitimate and not
junk-mail. You should only have to confirm your address once.

If you do not respond to this confirmation request within 14 days,
your message will not be delivered.

--===============0860186178==
Content-Type: message/rfc822
MIME-Version: 1.0
Content-Description: Original Message
Content-Disposition: inline

From: "ietf-sasl" <[email-masked]>
To: <[email-masked]>
Subject: Fw: DSC-00465.jpg

This is a multi-part message in MIME format.

------=_NextPart_2.12007641792297E-02
Content-Type: text/plain; format=flowed

forwarded message attached.

------=_NextPart_2.12007641792297E-02

------=_NextPart_2.12007641792297E-02--

--===============0860186178==--