Re: APOP - authentication..

> ] The current digest document lets the server choose between allowing old "nonce"
> ] values, in which case replay attacks are possible, or generating a new one
> ] every time, in which case replay attacks are no longer possible against a
> ] single server.

> Why?  There's an option to be just "kinda secure"? It sounds like if
> someone can sniff the wire to get an in-the-clear password, then they
> can sniff it to get replayable digests. In which case, digest is _not_
> a whole lot better than passwords, as some claimed when the future of
> digest was being discussed on the list a while back.

Of course there are options to be "kinda secure". In fact that's the only way:
Everything we do is only "kinda secure". Security is, and always will be, a
matter of compromise. Too much security makes things unusable. Too little makes
things too easy to break into. A balance has to be found between usability and
security. The only question is whether or not we've achieved the right balance.

The digest proposal lets servers accept previous nonce values should they so
desire. They are not required to do so, and the draft makes it clear that doing
so opens the door to replay attacks. The advantage, of course, is that it
avoids the challenge stage of the protocol.

Do I like or recommend the use of such an option? The answer is no, I do not. I
think the extra step to get a new nonce value is worth the cost. But that's
just my opinion, and others may feel differently about it.

There are also ways to strengthen the use of cached nonce values without
changing the protocol. The obvious one is to reject nonce values that are "too
old". Another options would be for servers to store the nonce value associated
with a given user and the IP address it was used from, and insist that only
this origin is eligible for reuse.

Another way to go about it, and one I would recommend, is to have clients
increment the nonce value each time they use it and have servers store the
nonce value last employed by each user so they can check it. This means you
have to leave some room in the nonce sequence you use to allow for the
increments, but this is easy to accomplish. A similar trick is employed by some
of the secure id box systems. This approach avoids the challenge much of the
time while defending againt replays.

The cost of all these things is the server having to modify a per-user database
entry. This may be cheap or it may be expensive. The question is the cost worth
the potential saving of a challenge operation in the protocol and the increased
security you get out of it?

> (I haven't seen a version announced later than the one trashed on
> www-security, nor since Jeff Hostetler said on 1/24/96 to Larry
> Masinter that they would be submitting a new digest draft.  I could
> easily have just missed it -- is there a new one?)

I don't know what version was reviewed there, so I cannot answer this.

> ] There is still some danger, however, in that the only material included under
> ] the checksum is the username and password. Should someone elect to use the same
> ] password with two different servers there is some possibility that should the
> ] nonce value sequences from the two servers overlap there would be some
> ] vulnerability to a replay attack of a client's interaction with one server on
> ] the other server.

> Do you mean "the only _other_ material" is the username and password,
> in addition to some nonce generated by the server?


> ] This could be easily defeated by using hash values for the nonce sequence
> ] rather than a strict ascending sequence as implied by the specification. And
> ] POP3's APOP is not necessarily immune from this attack, since there is no
> ] mechanism that guarantees that two different servers will generate different
> ] sequences of one-time values.

> Based on my reading of Peter's post, in APOP, the material covered by
> the digest includes the hostname.  (the "apop-realm" is digested, and
> it is a nonce concatenated with the hostname...) Why not just do the
> same for the HTTP version? Then there wouldn't be the possibility that
> the same password on different servers would generate the same digest.

First of all, the APOP documents don't require the use of the hostname. This is
merely a suggestion. It's a good suggestion, but it is not required, and
there's a good chance that careless implementors will elect to use a fixed
string for the hostname part of the challenge. We have far too much
experience in the exciting world of message id generation to believe otherwise.

Second, including host-uniqueness in the digest scheme is easy -- simply
encode it into the nonce value somehow.

The APOP scheme is stronger *only* in the sense that it includes a hint that
using the host name is a good idea. In terms of the actual protocol there is no
difference between the two in this regard.

There are also ways to attack APOP, even if you implement exactly what the
specification suggests -- APOP is vulnerable to something I call a "preplay
attack". (There may be a better name for it, but if so I don't know what it
is.) The problem is that if you use the suggested form of challenge an attacker
can predict future values the server will use. An attacker can then intercept a
connection from a client, send the client a challenge it knows the server will
use at some point in the future, let the client respond, store the value and
blow off the client, wait until the value comes up on the server, and then send
the response it got from the client. It isn't easy and it depends on a bunch
of factors, but it can be done.

There are two easy ways to address this. One is to use the output of a hash as
part of the challenge and use the pid and clock as input, but in addition salt
the hash with a private, unguessable value. This makes future challenges
impossible to predict, but means that servers have to maintain some secure,
unguessable salt value, which may be difficult. (Note, however, that APOP
servers have to maintain lists of user passwords in the clear, which means that
maintaining some extra salt as, say, an additional password value is not a big

Another way is to include the IP address of the client in the challenge. This
may not sound like much, but think about what it means in practice: An attacker
must be able to intercept incoming client connections and it must be able to
spoof the client's IP address to the server. If an attacker can do all this
they should also be able to break into a connection after authentication is
complete and take it over completely. If this is possible the strength of APOP
becomes irrelevant, so there is little point in making APOP stronger than this.

> ] I would prefer it if the nonce values in the digest specifications were simply
> ] strings and the specification recommended inclusion of server-unique
> ] information in the string. But this is a nit and nothing more -- it isn't
> ] enough of a deficiency in the digest specification to warrant the addition of
> ] APOP as yet another securty scheme. And even if it were, I think the better
> ] approach would be to fix the digest specification.

> I can't say until I've seen the new draft. BTW: I don't see APOP as
> "another" scheme -- if it's easier to just use APOP than fix digest,
> then I can't see why we should just use APOP. No one seems to have
> enunciated the reasons for digest -- only Roy's claim that there's no
> chance anyone will implement anything other that digest, without
> explaining why.

You cannot "just use APOP". APOP is hardwired into the POP protocol. It depends
on the characteristics of POP for the way it operates. You can pull it out and
wire it into HTTP, but in doing so you will end up with something that is
nearly identical to the digest proposal. If your only objection to digest is
that it allows but does not require reuse of old nonce values, "fixing" this is
easy and the result will be essentially the same as APOP as far as security
provided is concerned. Similarly, if APOP is pulled out and made into
a scheme of it's own, there is nothing to prevent someone from "breaking"
it in the digest sense.

In other words, the issue of whether or not cache nonce values are to be
allowed is both digest and APOP, and has to be addressed.


Received on Tuesday, 20 February 1996 23:05:14 UTC