Revisiting Defenses Against Large-Scale Online Password Guessing Attacks


  Revisiting Defenses Against.pdf (Size: 300.29 KB / Downloads: 0)


INTRODUCTION

Online guessing attacks on password-based systems are
inevitable and commonly observed against web applications
and SSH logins. In a recent report, SANS [20]
identified password guessing attacks on websites as
a top cyber security risk. As an example of SSH
password-guessing attacks, one experimental Linux honeypot
setup has been reported [18] to suffer on average
2,805 SSH malicious login attempts per computer
per day (see also [8]). Interestingly, SSH servers that
disallow standard password authentication may also
suffer guessing attacks, e.g., through the exploitation of
a lesser known/used SSH server configuration called
keyboard interactive authentication [19]. However, online
attacks have some inherent disadvantages compared to
offline attacks: attacking machines must engage in an
interactive protocol, thus allowing easier detection; and
in most cases, attackers can try only limited number
of guesses from a single machine before being lockedout,
delayed, or challenged to answer Automated Turing
Tests (ATTs, e.g., CAPTCHAs [24]).


RELATED WORK

Although online password guessing attacks have been
known since the early days of the Internet, there is
little academic literature on prevention techniques. Account
locking is a customary mechanism to prevent
an adversary from attempting multiple passwords for
a particular username. Although locking is generally
temporary, the adversary can mount a DoS attack by
making enough failed login attempts to lock a particular
account. Delaying server response after receiving user
credentials, whether the password is correct or incorrect,
prevents the adversary from attempting a large number
of passwords in a reasonable amount of time for a particular
username. However, for adversaries with access to
a large number of machines (e.g., a botnet), this mechanism
is ineffective. Similarly, prevention techniques that
rely on requesting the user machine to perform extra
nontrivial computation prior to replying to the entered
credentials are not effective with such adversaries.


Data Structure and Function Description

Data structures. PGRP maintains three data structures:
1) W: A list of {source IP address, username} pairs
such that for each pair, a successful login from
the source IP address has been initiated for the
username previously.
2) FT: Each entry in this table represents the number
of failed login attempts for a valid username, un. A
maximum of k2 failed login attempts are recorded.
Accessing a non-existing index returns 0.
3) FS: Each entry in this table represents the number
of failed login attempts for each pair of (srcIP, un).
Here, srcIP is the IP address for a host in W or a
host with a valid cookie, and un is a valid username
attempted from srcIP. A maximum of k1 failed
login attempts are recorded; crossing this threshold
may mandate passing an ATT (e.g., depending on
FT[un]). An entry is set to 0 after a successful login
attempt. Accessing a non-existing index returns 0.


Cookies vs. Source IP Addresses
Similar to the previous protocols, PGRP keeps track of
user machines from which successful logins have been
initiated previously. Browser cookies seem a good choice
for this purpose if the login server offers a web-based
interface. Typically, if no cookie is sent by the user
browser to the login server, the server sends a cookie
to the browser after a successful login to identify the
user on the next login attempt. However, if the user uses
multiple browsers or more than one OS on the same
machine, the login server will be unable to identify the
user in all cases. Cookies may also be deleted by users, or
automatically as enabled by the private browsing mode
of most modern browsers.


Decision Function for Requesting ATTs
Below we discuss issues related to ATT challenges as
provided by the login server in Algorithm 1. The decision
to challenge the user with an ATT depends on
two factors: (i) whether the user has authenticated successfully
from the same machine previously; and (ii)
the total number of failed login attempts for a specific
user account.