Yeah, it was kind of a "hey it does it for free" sort of thing.
I mean, if it's never really a problem, why spend more time setting extra things up. That being said, I'd have no problem setting up and managing HAProxy if we wanted to do that.
The fw boxes are from these guys: http://www.watchguard.com/ They were X550e's this weekend we're installing XTM 515's
Ahh ok, that explains why I've never seen that before.
I'm all for free, except when you're technically paying for it with licensing/etc.
I was totally serious about the $50-100 boxes being better than HAProxy, they're monumentally better at the basics. Where they don't do so hot is with SSL acceleration, but considering how fast AES-NI is, I don't bother doing that with loadbalancers anymore. Also fully HA and you don't have to deal with source/dest NAT issues if you're using DSR.
Tooting my own horn here, but I'm working on a book covering the Go Standard Library. Still in progress, and not at the sync package yet, but it's coming along. Check it out if you feel inclined.
You know what'd be cool? To take arbitrary code in a language, pattern match on the implementation in that language of each std lib function, and actively recommend substitutes for duplicated code.
That would be very cool. I wonder how hard it would be though. At least in Go I know that the standard lib contains lots of duplicate code (primarily so that things that should be small don't require larger things as dependencies. I think the time package's String() functions use reimplemented fmt package functionality for example, since fmt is a much larger dependency than time should have.)
Yes. What I mean though is that if you are reimplementing, say, fmt.Printf, such a suggestion system might correctly suggest you use fmt.Printf instead, but also suggest you can use func (m Month) String() string from time, or something equally silly.
Since the standard libs in Go duplicate code, you would have to be careful that your suggestion system isn't picking up false positives. I think the idea has a lot of promise though.
It can work the same way. You just slowly figure out the hash: this pw for this user was a bit faster than all the other failures, so we know the first byte of the hash is ...
If you have a bunch of hashes precomputed, you can start to figure things out pretty quick.
The point is it's still leaking information about what's going on.
This makes sense, I hadn't thought of knowing the hashing method and it being unsalted. Knowing those it would be just as easy to whittle the list down exactly the same way.
Err, not exactly the same way. Sure if you have a rainbow table of all the possible values of the hash construct then it would take a negligible amount of time. Doing the math of all possible values in the Hash space you will quickly see that at this point in time and space it's not plausible to have that.
You may then argue that you can have the value space of all popular passwords, but that isn't going to be any more effective than just trying all of the possible passwords.
I do have the sentence "This difference is enough to measure, even on web applications." in the fourth paragraph. Should I highlight that a bit, bold maybe?
I'd also like a good reference for that, and my Google skills were failing me. Do you happen to have a link to something show that off?
I missed that on the first read-through. Invariably when you introduce someone smart to timing attacks they will say "Oh, but that's not going to be practical over TCP/IP.
