Subject: [saag] Error Handling & Security

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Jun 2012 14:59:38 +0300

Hi all, 

I was wondering what the common practice is regarding error handling with respect to security. 

When I was student (a little while ago) I was always told that you do not want to provide an attacker with additional information, including information that is returned in error responses. This specifically had an impact on the error handling procedures for authentication protocols. 

For end users and developers it is obviously better to offer more information to let them figure out what had gone wrong. 

So, there seems to be a conflict. 

Experience or views from others? 

Ciao
Hannes

---

From: Jeffrey Schiller <[email-masked]>
Date: Mon, 18 Jun 2012 09:18:08 -0400

On Mon, Jun 18, 2012 at 7:59 AM, Hannes Tschofenig
<[email-masked]> wrote:
> When I was student (a little while ago) I was always told that you
> do not want to provide an attacker with additional information,
> including information that is returned in error responses. This
> specifically had an impact on the error handling procedures for
> authentication protocols.
>
> For end users and developers it is obviously better to offer more
> information to let them figure out what had gone wrong.
>

I believe the answer depends a lot on context and risk. Ask yourself
the question: "If I give a 'useful' answer here how will I be
empowering an attacker, what will they be able to do?"

Let's consider the simple and obvious case of user login. If you say
"username or password incorrect" [1], then you are divulging little
information, but a legitimate user won't know which part she got
wrong. On other hand if you say "no such user", then you have provided
some small information to the attacker. The attacker can then use your
login procedure as an Oracle to determine whether or not an account
exists.

But there are ways to thwart this attack somewhat. For example if
someone provides a different invalid username say three times in a
row, start returning "no such user" for all attempts, including ones
where the user *is* correct and maybe even the password.

Now three may not be the correct threshold. You want to set it high
enough that you don't confuse legitimate users, but low enough that
your login procedure cannot be used as a good Oracle. [2]

So my point is that you have to look at the trade-offs involved in
each situation and see if there is something you can do that preserves
usefulness for legitimate users while thwarting attackers.

                        -Jeff

[1] We'll ignore the issue of whether or not passwords are a good
    authentication technology :-)
[2] And in some situations even one "no such user" answer is not
    good. Consider the case of the porn site that uses e-mail
    addresses as login names. If you provide "no such user" only in
    the case where no such user really exists, then I can run your
    email address by their login procedure to see if you are a
    customer. Here the "harm" isn't compromising the site, but
    compromising the user :-)  [This isn't original to me, I read
    about this cute possibility on-line, but I forget where]

- --
_______________________________________________________________________
Jeffrey I. Schiller
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room E17-110A
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
http://jis.qyv.name
_______________________________________________________________________

---

From: Mouse <[email-masked]>
Date: Mon, 18 Jun 2012 09:59:34 -0400 (EDT)

> I was wondering what the common practice is regarding error handling with re$

Please don't use paragraph-length lines.

> [security considerations indicate returning minimal info in eg error
> resposnes, whereas developers and legitimate users want maximal info]

> So, there seems to be a conflict.

First, I'd remark that different cases have different needs.  This is
obvious enough, but the implication, that there is no one-size-fits-all
answer, seems to be easy to miss.

Knowing nothing about the particular case under consideration, if any,
my own preference would be to, by default, record helpful information
in server logs and return minimal information to the client.  (By
`server' I really mean `the peer performing the authentication' and by
`client', `the peer being authenticated'.  My remarks are aimed at
authentication/authorization exchanges, but, mutatis mutandis, they can
apply to others.)  In many cases, it can also be reasonable to provide
a way to configure the server to return more verbose information to the
client, for cases where the cost of the additional information exposure
is less than the benefit of the additional information; this can help
when, for example, running client and server on a closed development
network or when a server admin is trying to help diagnose a problem.
In some cases it may be enough to just give clients out-of-band (with
respect to the protocol) access to logs with the helpful info.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Marsh Ray <[email-masked]>
Date: Mon, 18 Jun 2012 11:21:07 -0500

> where the user *is* correct and maybe even the password.

How do we know it's the same "someone", in a way that an attacker can't
fool? I don't think we can. Password-based login from the server
perspective generally works like:

"A pseudonymous remote party has established an ephemeral session with
us. If the remote party demonstrates knowledge of Alice's username and
Alice's password, then this party is Alice and the session is upgraded
to a longer-lived 'login' session."

But legitimate users mistype their passwords all the time, so we can't
assume the inverse: "If this party fails to demonstrate knowledge of
Alice's username and password, then the remote party is not Alice."

If the password check fails, we know next to nothing about the identity
of the remote party.  We can log the source IP and port, but those can
easily be spoofed.

- Marsh

---

From: <[email-masked]>
Date: Mon, 18 Jun 2012 13:13:03 -0400

Of course the classic example of how not to do this was the Tenex
password error returns.

Tenex did a character-by-character comparison of the provided password
with a correct one and would return a page fault error if it couldn't
access the next character.  The result enabled a linear complexity brute
force attack on passwords.

For example, if the attacker already know the first 3 characters, the
next guess at the 4th character can be checked by positioning the
password in memory so that access to the 5th character causes a page
fault error, because the result is:
	- Bad password error: guess is wrong (4th character check failed,
		and Tenex did not try to access 5th character).
	- Page fault error: guess is right (4th character check passed
		because Tenex tried to access the 5th character).

I believe the general principle here is that error returns from an
authentication protocol should not reveal internal state information
on where/how the authentication failed.  The username/password discussion
below is an example of possibly revealing a little bit of internal state
(did the user check pass?).  As Jeff notes, a risk analysis of the
implications of exposing that info is appropriate.

FWIW, a good fix for the Tenex problem is to copy the entire password
into the OS before checking any of it, so that a page fault error doesn't
reveal anything useful (application already has other ways to know whether
a particular area of memory will vs. won't cause a page fault error).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jeffrey Schiller
> Sent: Monday, June 18, 2012 9:18 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [saag] Error Handling & Security
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iD8DBQFP3ypz8CBzV/QUlSsRApEOAKD0F2OJtIOHGjav6ygSqW3fCdUcLQCeOx5s
> ONVLo5w/jUh97gHWQHUwjLk=
> =o828
> -----END PGP SIGNATURE-----
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag