Software Security Seminar
March 25, 2010
A lightweight framework against
brute force login attacks on Web
Applications
Guy-Vincent Jourdan – Carlisle Adams
Jean-Pierre Levac – François Prévost
1
Introduction
In the late 80ies, Bishop and Klein started to bruteforce
a set of nearly 14,000 encrypted unix passwords
• 3.2% of the set was cracked in 15 minutes.
• “After over 3 CPU years of rather exhaustive
testing, approximately 40% of the passwords had
been guessed”.
• In the first week, nearly 21% were cracked
• This confirmed the known fact that users tend to
choose “bad” passwords ....
• ... but that was rather encouraging otherwise.
http://nob.cs.ucdavis.edu/bishop/papers/1995-c+s/proact.pdf
Software Security Seminar 2
Introduction
Things have seriously degraded ever since:
• Users still choose easy-to-guess password
• We are literally dozens of passwords to remember
• Often the situation is only made worst with silly
security policies
• But more than anything else, it can be argued (and it
has been!) that the time that you could memorize a
password that cannot be cracked is behind us!
• See e.g. the following (already old) analysis:
http://www.schneier.com/essay-148.html
Software Security Seminar 3
Introduction
• Yet, password are used all over the place, all over the
internet. They are not going away.
• In fact, there is often no real, practical alternative to
this cheap, ready-to-use solution to authenticate
users
So ... there is no hope?
Software Security Seminar 4
Introduction
• It is not completely over! Most of the doom-and-gloom
stories around password-based authentication system
relate in fact to off-line password guessing attacks.
• Usually, off-line guessing is not possible. On-line
guessing is a very different story.
• In the paper “Do Strong Web Passwords Accomplish
Anything”, Florêncio, Herley and Coskun point out
that if on-line guessing is slow enough, the
entropy of the pair UserID+Password do not need
to be large at all.
http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf
Software Security Seminar 5
The challenge
• We want a system that can be used to slow down
password-guessing on-line attacks
• However, “password guessing” is just one way of
finding an account. An often more effective approach
is “ID guessing”, where a common password is
selected and a matching ID is searched
• Note that many web application do not have any
particular mechanism against ID guessing
• In fact, protecting against ID guessing is often
somewhat difficult since, unlike IDs, passwords are
not unique in the database.
Software Security Seminar 6
(ID guessing... Does it exist?)
There is strong evidence that ID guessing would be
effective, based on leaked password databases:
• 2007: 43,713 passwords leaked from MySpace
Top password: password1 (0.23%)
• 2009: 9,843 passwords leaked from HotMail
Top password: 123456 (0.65%)
• 2009: 32,000,000 password leaked from rockyou.com
Top password: 123456 (0.90%)
http://www.the-interweb.com/serendipity/index.php?/archives/94-A-brief-analysis-of-40,000-leaked-MySpace-passwords.html
http://www.acunetix.com/blog/websecuritynews/statistics-from-10000-leaked-hotmail-passwords/
http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf
Software Security Seminar 7
(ID guessing... Does it exist?)
• Logs of attacks of this type have been reported
http://tacticalwebappsec.blogspot.com/2009/09/distribut
ed-brute-force-attacks-against.html
• It seems that attacks like this have been occurring
against some university’s system
Software Security Seminar 8
The challenge
We want a system that
• Can slow down password-guessing attacks
• Can slow down ID-guessing attacks
• Can slow down ID-Password-guessing attacks
• Cannot be abused to deny access to user (and
prevent users from kicking themselves out by
mistake)
• Handles gracefully (Distributed) Denial-Of-Service
attacks (at least recovers from it gracefully)
• Does not leak any information (no timing attacks)
Software Security Seminar 9
The challenge
We want a system that
• Can be adapted to small and large web sites alike
• Is fast
• Is very easy to use in an existing Web Application,
with minimal impact on the code
Software Security Seminar 10
The solution
We define three “directions” along which to protect:
• ID direction
• Password direction
• IP direction
(note: the IP direction is problematic in practice, for the
usual reasons: DHCP, AOL...)
Software Security Seminar 11
The solution
Along each direction, we maintain a sliding window
defining the maximum number of requests per value
acceptable in the window
Once the threshold is reached, that particular value is
denied processing for a set amount of time, after
which processing is resumed
Software Security Seminar 12
The solution
This simple technique can be used to slow down attacks
in each direction as much as wanted by decreasing
the number of allowed requests in the sliding window
It will also prevent any (long lasting) denial of service
since the blocked value will soon be allowed again
Even with a massive DDOS, the system should recover
almost as soon as the attack stops
Software Security Seminar 13
The solution
Problem: how to efficiently calculate the number of hits
within the window?
Software Security Seminar 14
The solution
Problem: how to efficiently calculate the number of hits
within the window?
If we allow up to d events in a window in size w, then
each event closes the window by w/d
front”
“tile “tile front”
w/d
time
ww
Current time
Current time
Software Security Seminar 15
Implementation 1: PHP
• A full login system implemented in PHP
• An independent, indexed table of password is added,
with a link table between ID and password
• Invalid ID and Passwords are added to the tables
when processed
Software Security Seminar 16
Implementation 1: PHP
• The system is fast, even under attack
• Live at http://bruteforce.jeepink.com
Software Security Seminar 17
Implementation 1: PHP
Limitations with the PHP implementation:
• This tool replaces the existing authentication
mechanism, so it is difficult to integrate in an existing
application
• It make the whole authentication mechanism a lot
more complex: separated password table, storing of
wrong IDs and wrong passwords, password changes
more complex...
• As such, it probably leaks timing info too....
Software Security Seminar 18
Implementation 2: Java
A much better approach: separate the protection for the
actual authentication:
• Dynamically create 3 totally independent lists (one per
direction), keeping track of the “tile front” of each entry
• Store in memory for fast access (built from scratch at
each reboot, separated lists in clustered environment:
so what?
• Pass on the login request (transformed (hashed) if
you want). Returns OK or not OK (with a reason)
• If OK, go on with your actual login.
Software Security Seminar 19
Implementation 2: Java
• Cannot leak information (doesn’t have any)
• Very easy to integrate:
if(AttackCheck.isBlocked(request.getParameter(“ID”),
request.getParameter(“PWD”),
request.getRemoteAddr()){
doSomething(); return();
}
...
Software Security Seminar 20
Implementation 2: Java
• Current implementation uses Hash table
• Background incremental garbage collection, and
forced garbage collection if MAXSIZE reached
HashTable
Average 6000 login: 0.7395 ms
Average 6000 logins: 0.688 ms
Average 6000 logins: 0.6765 ms
Average 6000 logins: 0.7185 ms
LinkedList
Avec algorithme avec cleaning:
Average 6000 logins: 1.682 ms
Average 6000 logins: 4.13 ms
Average 6000 logins: 18.69 ms
Average 6000 logins: 27.068 ms
Average 6000 logins: 46.27 ms
Average 6000 logins: 23.3748 ms (garbage collection)
Software Security Seminar 21
Some limitations
• If your system has a very common password and
known IDs, then slowing down attacks against this
password might be impractical because the window
has to be shut too small
• The window of the IP direction must be smaller than
the IP and the password one, to prevent DOS attacks
(to be balanced with the shared IP problem)
• For the IP direction to be effective in prevention of
DOS attacks, the login process should be a two steps
process
Software Security Seminar 22
Some limitations
• We have introduced a risk of (distributed) DOS on
common passwords (balanced against the
“eliminated” risk of breaking into the corresponding
accounts)
• There is a limited risk of our system being itself
attacked via flooding (must be distributed)
• Finding the right window size for your context?
Software Security Seminar 23
Conclusion
• Want to try it? Let us know!
• Want to port it? Let us know!
Software Security Seminar 24