Re: [kitten] RFC5802: question about unknown-user error

[Jehan Pagès <[e-mail]>]

Hi,

so I catch up on this topic as well. Sorry also for the late answer.

On Sat, Dec 4, 2010 at 8:04 AM, Chris Newman <[e-mail]> wrote:
> Not only do I disagree with your proposal to remove the no-such-user error,
> I consider it a useful capability for several use cases of a general-purpose
> protocol.
>
> When it comes to a threat analysis of an entire system, sometimes hiding the
> no-such-user information has no security value at all and thus the
> diagnostic/maintenance benefit of the error becomes important.
>
> For example, in SMTP servers, spam/virus/phishing is the #1 threat and the
> related denial of service attacks are important. Since it's impossible to
> detect spam/virus/phishing content until an after the DATA has been
> transferred (costing a lot of Internet bandwidth), it's important to reject
> an email with all invalid mail addresses before the DATA in order to
> minimize the denial-of-service impact on the mail server. So the ability to
> probe for valid mail addresses is present in a properly configured system.
> While administrators can choose to have mail addresses different from login
> identities that has a usability impact some administrators find
> unacceptable. So if they're the same, then on a properly configured mail
> system, whether an account is valid or not is public information. So the
> no-such-user error provides no additional information to attackers, but it
> provides very useful information to end-users and service desk teams.

If an attack intends to do a Denial of Service, they have many other
ways. They don't need to have big DATA or whatever. They can just make
many connections in the same time. At this point, refusing the email
before the DATA does not protect at all against a DOS.

On the other side, by giving away the information about which account
are valid and which are not in your example (or through other ways,
like through the SCRAM authentication), you enable the
spammers/phishers/other malevolent people to know who are the real
targets, hence to become more efficient and spare their resources: the
next time, they won't spam the accounts they know don't exist (as
anyway nobody will read the spams) but will spam much more the
accounts which do exists.
So this configuration you propose to "protect" your servers do indeed
increase the effects of what you called yoursel the #1 threat in
emails.

> I could also argue that the actual security has to come from the password,
> since there are so many other ways that usernames can leak. So pretending
> that usernames do not leak to attackers becomes a self-delusion that
> prevents sysadmins from paying proper attention to password security.

I do not say that usernames cannot leak otherwise. But that's not
because they may leak by some other mean that we should become light
headed on this matter. At the opposite, when we can protect this
information, let's do it. For the rest when we have no control (like
if users go and write everywhere their emails to be collected by bots,
if we stay in the case of emails), well at least we made our part.
Here we are discussing about a leak which gives full information on
the server's usernames. This is different from many other kind of
leaks (like the ones from the user itself, which gives leaks one at a
time).

Thanks.

Jehan

> That's not to say I entirely disagree with your concern. There are many,
> perhaps the majority of use cases where obscuring username validity
> increases the magnitude of the attacker's problem enough to have real-world
> value. But SCRAM has sufficient provision for these cases already.
>
>                - Chris
>
> --On December 4, 2010 1:53:39 +0900 Jehan Pagès <[e-mail]>
> wrote:
>
>> Hi,
>>
>> 2010/12/4 Tobias Markmann <[e-mail]>:
>>>
>>> On 03.12.10 15:36, Jehan Pagès wrote:
>>>>
>>>> For me the current unknown-user error is a big security flaw. I would
>>>> propose to remove this error, and add a security notice about this.
>>>> Has this issue already been raised?
>>>
>>> Almost any information you return on failure, beside the failure itself,
>>> can be used by a malicious user against a server. I think that's why the
>>> whole server-final-message is OPTIONAL in case of an error.
>>>
>>
>> Most other error are far less usable for attack. They are rather
>> syntax bugs, which are very useful for normal implementers and would
>> only tell an attacker that he made a technical error in his own
>> implementation. But it does not give away information about data
>> stored by the server (like "does this username exist?"), other than
>> what he would have known with a proper implementation. Those errors
>> are for instance encoding issues, CB incompatibility, incompatibility
>> of mandatory extensions (for the future when there will be some), etc.
>>
>>> Those error messages only seem useful for debugging purposed, since some
>>> protocols using SASL, i.e. XMPP, provide SASL errors on that protocol
>>> level [1].
>>
>> Good example If you check the link you give (the last draft of the
>> updated RFC has similar content as well:
>> http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-19#section-6.5 ),
>> in XMPP, we use only one error (<not-authorized/>) whether you fail
>> because of a wrong password or because your username does not exist,
>> for instance. The attacker does not know if he is wasting his time on
>> this attack, nor can he fill his db with any useful data on existence
>> of a JID.
>>
>> So of course that's nice when the higher level protocol filters the
>> SASL errors (in XMPP, we closed the leak created in some SASL
>> mechanisms like SCRAM), but I don't see why it should prevent us from
>> fixing this data leak on the SASL-SCRAM level as well.
>>
>>>
>>> A security notice about this would be nice but actually the problem
>>> isn't specific to SCRAM but to nearly all SASL mechanisms.
>>>
>>
>> I agree about this, but first we can fix this in SCRAM by removing the
>> unknown-user error; and then we can add a security notice in SASL,
>> telling that SASL mechanisms should take care about this kind of leak.
>> There are 2 levels of RFC changes here.
>>
>> Jehan
>>
>>> Cheers,
>>> Tobi
>>>
>>> [1] http://tools.ietf.org/html/rfc3920#section-6.4
>>>
>>> --
>>> Tobias Markmann
>>> http://ayena.de
>>>
>>>
>> _______________________________________________
>> Kitten mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/kitten
>>
>
>
>
>
>