Request for feedback: how slow is your slowest MAAS cloud?

[John A Meinel]

Note also that I do have a stake here, as this is what we do for Juju. Its
perfectly fine to wait 1s for a user-initiated login to get a response. But
when you have 1000 agents that are restarting at the same time because you
bounced the controller machine, it takes a *long* time for them all to get
reconnected if you're spinning CPU cycles in a 1M iterated SHA hash loop.
And it seems far more efficient to get 1M more time spent in brute force
attacks by adding 20 bits (~5 more hex digits), to the key.

John
=:->


On Fri, Jun 2, 2017 at 12:05 PM, John Meinel <john at arbash-meinel.com> wrote:

> I'll note that if you're generating a password, there really isn't a
> reason to then pbkdf2 it, is there? I thought the reason to use pbkdf2 was
> because it is too easy to generate SHA hashes for common *human* passwords.
> But as the brute-force search spaces increases exponentially with more
> bits, just generate longer passwords.
>
> So if you are generating a random password, just make it 50 /dev/random
> bytes long, and then you can use just simple 'sha' as the mapping back to a
> password hash.
>
> At least, my understanding is that scrypt/et al exist because Humans
> cannot remember good passwords, so they get massaged into slightly better
> passwords by lots of rounds. But if you just started with more entropy in
> the password, you don't have to worry about that.
>
> John
> =:->
>
>
> On Fri, Jun 2, 2017 at 6:59 AM, Seth Arnold <seth.arnold at canonical.com>
> wrote:
>
>> On Thu, Jun 01, 2017 at 05:46:52PM -0700, Mike Pontillo wrote:
>> >    In doing so, I'm looking at deriving an shared key that can be used
>> to
>> > encrypt network traffic between peer rack and region controllers, and
>> > eventually commissioned machines. The industry standard for key
>> derivation
>> > is the PBKDF2 algorithm, which makes brute force attacks to derive the
>> > password from the key harder (by repeatedly running a hash function).
>>
>> PBKDF2 is also fairly old; I believe most cryptographers would prefer
>> argon2, scrypt, or bcrypt to PBKDF2, with a grudging acceptance that if
>> you have to sell into the FIPS marketplace you may not have a choice.
>> Do we have a choice?
>>
>> We should also worry about the asymmetry of attackers vs defenders.
>> Hashcat on gtx1080 GPUs can crack roughly a thousand of these
>> million-iteration PBKDF2 per second.
>>
>> (I'm extrapolating a bit from the data easily available. This forum post
>> says the benchmark uses 1000 iterations:
>> https://hashcat.net/forum/thread-5799.html
>> And these results say that it can run over a million per second:
>> https://gist.github.com/epixoip/6ee29d5d626bd8dfe671a2d8f188b77b
>> https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40
>> So my assumption is one thousand times the work means a one thousand time
>> slowdown. I haven't tested these speeds myself.)
>>
>> This points out that no matter how expensive the KDF being used,
>> passwords such as '123456' 'monkey' etc are always terrible. It might
>> take the controllers one second or so to generate the key, but given a
>> password in the usual top-1000 list of passwords, hashcat can break it
>> in about the same time it took to generate it.
>>
>> Thanks
>>
>> --
>> Maas-devel mailing list
>> Maas-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/maas-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20170602/0f9c098c/attachment.html>