* 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.
Thanks!
Stephen
signature.asc
Description: Digital signature
