Circle Bank plays with two-factor authentication

[Ed Gerck]

Steven M. Bellovin wrote:
> I'd like to hear why you think the scheme isn't that usable.  I disagree
> with you about its security.

The first condition for security is usability. I consider this to be
self-evident.

Users have difficulty already with something as simple as username/pwd.
Here, the user is additionally requested to find three numbers that match
(for example) G5:H1:D3, out of 40 matrix positions in 8 columns and 5 rows.
Anyone who has played battleship knows that matrix searching takes time and
mistakes happen.

The screen is likely to time out while the user is looking for the 3 numbers,
so that the user has to start again, possibly with another new time out. The
user may also make a parallax mistake, getting a wrong number. After the user
logs in the session times out after a while, requiring the same procedure anew.

Users will have a hard time using this. But I don't think there is so
much of a need to advocate for the users here -- they will just go back
to phone service (which costs much more for the bank). Eventually, because
of cost, something with higher usability will have to be used.

The introduction of a USB interface for SecurID was caused by user rejection
of a much simpler procedure -- the user just had to read the two-factor code
off a display.

> The question is what the threat model is. 

We agree they should not have included the sign on ID. It is not such a
quick fix, however, to delete it from the message because different
accounts may share the same email address and the user would not know
what matrix to use for what account. But such a simple, clear mistake is
actually a harbinger -- there are other clear mistakes there. But which
cannot be solved.

For example, the scheme (contrary to SecurID) has no protection against
an insider threat (the highest risk). The matrix combinations are fully
known in advance from the bank side (and there are only 999 of them [*]).

Further, it does not allow the usual bank security policy of separating
development (inside knowledge) from operations (the bank's servers).
Watching a couple authentication events for a user should be enough to
find which matrix the user was assigned to, allowing the next authentication
event to be fully predictable without any cooperation from or attack on the
user.

After the severe usability burden of this scheme, one would think that
the threat model would be more robust -- to pay for your troubles.

There are, of course, also the outside threats. Contrary to what
people think, it's very common and very easy to intercept email.
ISPs can do it without trace. Companies do it all the time for
their employees. Of course, ISPs and employers already show trusted
functionality to the user but the use of insecure email here
multiplies the inside threat opportunity against the user.

There's also the question of plausible deniability. If the user's
username/pwd is compromised today, it's easy to argue it was not
safe to begin with. With this scheme, people (and the user) might
think the user is more protected -- when the user may actually
be more exposed.

Shifting the burden to the user is tempting. But, contrary to risks,
shifting the usability burden is less tolerable to users. As
technologists we cannot just do the math and say -- it works! This
was the same mistake of email encryption. That the system can actually
be used turns out to be more important than any security promise.

Cheers,
Ed Gerck

(*) Apparently, at most. Their 3-digit matrix counter, also included
in the message (!), can index at most 999 pages.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com