From: Ilmari Karonen on
On 2010-03-03, Greg Rose <ggr(a)nope.ucsd.edu> wrote:
> In article <hmlc1p$94o$1(a)news.eternal-september.org>, JR <p(a)pnp.com> wrote:
>>
>>Will truncating the MAC reduce the security of the whole thing?
>>i.e. I assume the MAC size depends on the size of shared secret key.
>>The bigger the shared secret key, the bigger the size of the MAC for one
>>particular size of the original message - am I right in this?
>>If I am right, will truncating the MAC compromise anything?
>>What I can do avoid the reduction in security? What should be the
>>size of the shared Key?
>
> Truncating the MAC will obviously reduce the
> security against forgery; this is unavoidable in
> the scenario you have presented. However, you can
> adopt a lesson from the bank teller machine. The
> bad guy can't check whether the MAC is correct
> himself; he has to ask someone else to check it
> for him. Just ring alarm bells if anyone fails MAC
> verification a few times in a short period. This
> is like disabling or eating the ATM card if the
> PIN fails three times in a row.

Alternatively, as I suggested in my original message, you could limit
the rate at which the machine accepts authentication attempts. For
example, if the machine locked up for ten seconds after each failed
attempt, an attacker with access to a single machine would need on
average about two months to guess a single valid code, assuming they
could keep trying new codes around the clock.

If two months sounds a bit low, or if you're worried about attackers
targeting multiple machines in parallel, you can either add a few more
bits to the MAC length, increase the delay or combine it with Greg's
suggestion of a longer lock-up and alert after some larger number of
failed attempts. In fact, it's probably best to do both in any case.

(Also note that you'll probably make your legitimate users happier if
you limit the rate to three attempts within each minute rather than to
one attempt every 10 seconds, even though the former actually slows
down an attacker twice as much. After all, users do sometimes make
typos, and it's nice to get one or two chances to quickly retype the
authentication code before having to wait.)

A lot here depends on just what the full situation is: how many
machines are there, can they be accessed remotely, how much might
gaining unauthorized access be worth to someone, and, conversely, how
much is preventing that from happening worth to you?

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.