Re: Measures of detecting breached email accounts

[Joseph Tam <tam () MATH UBC CA>]

Valdis Kletnieks <valdis.kletnieks () VT EDU> writes:

> Note that this can be distinguished from "somebody forgot to update
> the saved password" because a student trying different passwords won't
> be issuing the attempts every 5 minutes on the nose.

I beg to differ.  It was happening as I wrote this Email.

        [Many entries like ...]
        Dec 12 15:43:32 imap-login: Disconnected (auth failed, 2 attempts in 14 secs): user=<{user}>
        Dec 12 15:44:32 imap-login: Disconnected (auth failed, 2 attempts in 14 secs): user=<{user}>
        Dec 12 15:45:32 imap-login: Disconnected (auth failed, 2 attempts in 14 secs): user=<{user}>

This is a valid Thunderbird users failing every 60s "on the nose"
+/- clock drift.  Other readers may have other intervals.

> Similarly, most "trying a variant on a broken password software" won't
> spread the attempts out and try a new variant every 5 minutes, because
> that ends up lowering the success rate.
> ...
> So you can distinguish both those cases from "forgot to update password".

If you track *single* IPs or account.  We have BFD sessions against one
or more accounts round-robining IPs through a bot pool.  Any particular
IP will not show up often.  To make it murkier, the *real* owner sometimes
authenticate in the middle of this maelstrom.

Conversely, we have had users trying to cope with dodgy network services
by relocation or power cycling their gateway, or simply riding a bus with
roaming wireless service.  These users acquire bunches of different IPs,
and if you mix in bad passwords, you have log entries that will tax your
ability to discern benign failures from a real attack.

This was unravelled retrospectively after users made problem reports.
Prophylactic investigation based on failed logins would have been a
colossal waste of time.

> And if somebody *does* have a legit reader that *does* start looping
> and hammering on one password every millisecond when it fails to
> authenticate, and as a result looks like a password cracker, you
> *still* want to know about it, just so you can tell the user to update
> his damned software so it's not bogging down your LDAP (or whatever)
> infrastructure.

1000 (or even 10) logins/second for prolonged periods would count as
aberrant.  Malicious or not, it's worth investigating.  However it's
the volume I'm paying attention to, not the failure.

The fact I didn't even have to look further than my current logs to find
examples of what you consider aberrant should attest to how prevalent it
is.  That's from a few hundred users -- I don't know how you would scale
your aberrant criteria to 10K users and still be able to pick out signal
from noise.

If the analysis you're doing yields valuable actionable results, far be
it for me to suggest you do otherwise.  However, I haven't seen evidence
to make me pay attention to failed logins.  It seems much more productive
to analyze the characteristics of a successful login.

Joseph Tam <tam () math ubc ca>