[ale] any suggestions on an automated method for blocking repeated failed ssh login attempts?

[Michael Trausch]

I am sorry if the reply didn't go in-thread (that also means that there is
little chance that this one will be in-thread, as I am using the same email
software on my phone to write it.  I need to get off my lazy ass and write
an email client for Android that works the way it ought to, with proper
support for encryption, digital signatures, threading... and mod the system
to support a LUKS encrypted SD card, and... nevermind).

I was indeed referring to you (MWH), and I was replying to the message
asking about your thoughts on login delays.  I hope that provides sufficient
context.

Also I was mentioning a system that employs encryption (of course I didn't
write the encryption code in it; I am nowhere near qualified enough for
that, nor am I qualified to review or audit the source code of the
encryption used, so it is a black box to me) which I am writing for the
purpose of creating a "perfect backup" (lossless w/ acl/xattrs, compressed,
random-access at the file level, encrypted, able to span multiple media and
retain all of these properties).  But I do know that passwords require
transformation before they can be used as keys, and I know that KDFs do a
large part of that, in concert with salting and hashing, and that the number
of iterations has a natural impact on delay.

--
Sent from my G2 running CyanogenMod!
That is, a phone. :)
On Dec 23, 2010 11:58 PM, "Michael H. Warfield" <mhw at wittsend.com> wrote:
> Michael,
>
> No offense but I'm totally at a loss to see who or what you were
> responding to with this. Can you reply in-thread with some quoting? I
> see what you're saying and not understanding your point. I'm presuming
> that the "Not sure what is reply is going to be" may be referring to me.
> My access is a little erratic right now during the holiday season so
> you'll have to forgive me a bit.
>
> Regards,
> Mike
>
> On Thu, 2010-12-23 at 18:48 -0500, Michael Trausch wrote:
>> Not sure what his reply is going to be, but I can say that if there is a
>> delay, it should be inherent to the method of key generation. For
example,
>> if using a strong password as input to a KDF that runs a million rounds,
>> there will be a noticable delay to the key generation. Sadly, there is no
>> way to pick a universally applicable number of rounds, though; very old
>> systems won't be able to reasonably generate keys if there are more than
>> several tens of thousands of iterations, while very new systems may not
>> delay at all.
>>
>> I have one system-in-progress that is setup to generate keys with
10,000,000
>> rounds, making the delay on my system around three seconds to generate
the
>> key. In the target environment it takes ~10 seconds. The only purpose is
>> to reduce the feasibility of brute forcing by increasing the time it
takes
>> to generate a key.
>>
>> It seems that 1,000 to 10,000 iterations is the common value, but on my
>> systems this provides nearly no delay whatsoever. Certainly not one which
>> is perceptable to me. Given a 3 second delay to generate a key that would
>> mean that it my system can only brute 120 keys per minute, if those keys
all
>> pass through the algorithm. It also means that invalid passwords will
take
>> some time, even locally, to find that they are invalid, which is the
point
>> with something like this where there may not be a client/server
interaction.
>>
>> --
>> Sent from my G2 running CyanogenMod!
>> That is, a phone. :)
>> On Dec 23, 2010 6:34 PM, "Matty" <matty91 at gmail.com> wrote:
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>
> --
> Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
> /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> NIC whois: MHW9 | An optimist believes we live in the best of all
> PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20101224/f659d3dd/attachment.html