* Bruce Momjian (bruce@momjian.us) wrote:
> On Sat, Mar 7, 2015 at 03:15:46PM -0500, Bruce Momjian wrote:
> > > Gave me 9.15s, or ~0.00915s per connection on a single thread. That
> > > times 16k is 146s or about two and a half minutes. Of course, I'm
> > > comparing this against what we currently do since, well, that's what we
> > > currently do. Changing it to 4b would certainly improve that. Of
> > > course, using multiple threads, having multiple challenge/responses on
> > > hand (due to listening for a while) or simply breaking the MD5 hash
> > > (which we know isn't a terribly great hashing algorithm these days)
> > > would change that.
> >
> > Uh, my calculations show that as 434 days of trying. (Not sure why you
> > didn't bother doing that calculation.) I think anyone who is worried
> > about that level of attack would already be using MD5. Again, MD5 is
> > mostly used in low-security settings where you just don't want the
> > password sent over the wire in cleartext. Frankly, without TLS, you are
> > already sending your queries and data across in clear-text, and there
> > are other attack vectors.
>
> Actually, with a counter, the bad guy just has to wait for the counter
> to roll around, and then try to catch the counter on the values he has
> recorded, meaning you wouldn't even be able to detect the hack attempts.
> :-)
That's true, if the counter is at an individual-level. If it's cluster
wide then they aren't very likely to have the same counter for the same
individual after the wrap-around. Then again, what individual is going
to be logging in 4 billion times? There's a number of trade-offs here,
which is why we'd really be better off using an approach which security
folks have already vetted.
Thanks!
Stephen