* Bruce Momjian (br...@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.



Attachment: signature.asc
Description: Digital signature

Reply via email to