Feature idea/request

[Jason Schmidt]

For those using the clipperz site instead of the community version, the offline backup option is wonderful, but to use it you must be logged in to clipperz, which would require backing up manually every time (or worse yet, storing your super-secret password in a script file).  Would it be possible to pass the "userid" externally (at least the hashed user/password combination) to the offline dump script ( https://www.clipperz.com/beta/dump/?user=... ) so that it would be possible to enable automatic offline backups?  The user's hash can easily be obtained for embedding in a script by manually downloading one offline backup, then searching for the string "catchAllUser".  It's right after the second occurrence in the portion populated by the server-side script, of course.

Thanks,
-Jason

[Giulio Cesare Solaroli]

Hello Jason,

the idea is sound and we will take a closer look at it; the only fear
I have right now is that this new call could be used as an effective
way to perform a dictionary attack on our DB.

Right now, to perform a remote dictionary attack on Clipperz the
attacker needs to go through 3 full SRP connection procedures, each of
wich consists in three steps; so in order to verify if a given
username/passphrase is valid the attacker will have to pay 9 hashcash
tolls.

With the direct link, an attacker would be able to achieve the same
result immediately. At least with a naive implementation. We could
alleviate this problem always returning a well formed offline copy,
but with dummy data, so that the attacker will be forced to test the
credentials also on the downloaded file.

But this will definitely create some added cost on our server, and
could expose us to a very simple way to take our server down to its
knees.

Nice idea, but we need to work on it further to solve these issues.

Thanks for your suggestion.

Best regards,

Giulio Cesare

[Jason Schmidt]

Hello Giulio,

Thank you for taking the idea into consideration.  I'd be happy to help develop the concept and the source code to support it.

You're absolutely right that it would make a dictionary attack easier.  As I understand it, the "username" field is actually a hash of *both* the user-name and password, which would require them to (expensively) attempt every combination of known user names with dictionary-based passwords, and that would show up rather clearly on your network logs.  A simple throttle on the frequency of failed requests allowed per IP on the dump service might be a suitable protection against such an attack (by slowing down the "failure" response, not by denying access).  I suspect your servers would have trouble with any distributed attack (most do), making the strain in that situation unavoidable.  I should hope your server is never brought to its knees, though!

Considering that the offline copy is guaranteed to be a relatively "large" file (consuming some processing time and a fair amount of bandwidth), you could also enforce a global limit on the process.  A few second's worth of delay would certainly seem acceptable when using it legitimately, and would add delay and cost to any dictionary attack.  You could also force serialization of requests from sources, so that each source may only attempt one pull at a time, further frustrating any attacker.  These, of course, are mostly network based solutions, though they are implementations that can be done in the server-side scripts.  Since the goal is to cost an attacker unreasonable amounts of time in testing passwords, arbitrary delays will work as effectively as additional hashcache generation, and possibly cost your server many fewer CPU cycles, because it only needs to remain idle.

Returning chaff data generated with an invalid request would certainly make things more difficult, but that particular solution would slow down your server because random numbers take time to generate.  Perhaps a suitable alternative would be to only generate a random user record and then pull several random cards from the database, since the cards are already indistinguishable from random data without the correct key and pulling data from the database should be faster/easier.  If you're using a *nix based server (and I assume that you are), you could also create a file-based FIFO, and pipe incoming, valid card data *into* it without any formatting (just the random-appearing parts, not the full JSON transport), then read *out* from that whenever you need random data quickly, but don't want to incur the cost of generating random data.  Likewise, you could simultaneously have a low-priority background process constantly pumping a few truly random numbers into that stream to further confuse things.  Just remember to always return the same username/password hash that was provided, so that it always looks valid, and they have to attempt an actual decryption of the data.

Thanks for listening!

Be well,

Jason Schmidt