[Cialug] Webserver mitigation against BREACH

[Zachary Kotlarek]

On Aug 6, 2013, at 12:00 PM, Nicolai <nicolai-cialug at chocolatine.org> wrote:

> What are the related options in Apache?  Other webservers?


There are also fixes application-side (or application-delivery-side, if you have access to such a system) if you don't want to mess with the HTTP side of things.

The simplest one is just to use denser secrets. This attack reduces the complexity of the secret by breaking it one character at a time, so the more data you can pack into a single character the harder it is to guess. Just switching from hex encoding to base64 encoding for your secret will add quite a bit of resistance (6 bits per character vs 4). Longer secrets will also increase the number of requests needed, but only linearly; increasing the data density makes the attack geometrically more expensive.

Another option is proactive re-keying. Changing your secret data every X requests would be quite effective (and if you change the secret for every request it provides protection against a whole slew of other attacks to boot). Given a 32-character secret this attack requires something on the order of thousands of requests, so if you simply re-key after every 100 requests you can effectively avoid it even without detecting it.

On the active side you could monitor for bad auth events (i.e. wrong cookie guesses) and lock out sessions that are in the process of such an attack; you might not want to blow up after 1 or 2 bad cookies, but if you see 25+ there's *something* wrong and you probably want to re-auth the user regardless of the underlying problem.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2746 bytes
Desc: not available
URL: <http://cialug.org/pipermail/cialug/attachments/20130806/ce14ebbb/attachment.bin>