I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid Python.
People should use proven KDFs for password authentication, not implement their own (including using my SHA-salting/iteration examples.)
I personally agree that "Use bcrypt." should become "Use scrypt." soon. My main gripe is that there is far less library support for it, at least for now.
Although it's not that much if you're using a long hash, iterating a hash function causes you to lose entropy. The implementation in the article is basically PBKDF (1). PBKDF2/HMAC avoids this by making an "outer" and "inner" layer.
I agree there are a ton of articles saying "Use bcrypt." After Coda's post (http://codahale.com/how-to-safely-store-a-password/) it's almost become a meme. I don't, however, think that the people who say "Use bcrypt!" tend to explain why they say that.
I think the reason that this happens so often is that regular developers just don't care. But that's because they don't know why they should care. Given a proper explanation (and an attention span longer than "Squirrel!"), any reasonable developers would (at least, should) care.
Indeed. There's a developer bubble around Hacker News and websites like Stack Overflow, where topics like bcrypt have become second nature. Whereas standard developers, i.e. those that program solely as a job, they don't inhabit these places.
If a company with a large and complex web property, e.g. Microsoft.com or Google.com, asked you if it mattered whether they allow DNS AXFR, what would your answer be?
So you agree that disabling AXFR, if AXFR is enabled, is a good idea?
Could you explain why you think wide-open-dev-machine.customer.com is NOT safer without AXFR (assuming it blocks robots, and the web server only serves the site for "wide-open-dev-machine.customer.com")?
I'm just trying to understand how it could not be considered beneficial in any way, however much (which is what you're claiming).
I don't have to think about this much because nobody has AXFR enabled. If you had AXFR enabled, I would in fact tell you to turn it off. It isn't an operational win (unlike SSH on port 22), so what possible reason could there be for enabling it?
wide-open-dev-machine isn't safer because there's a whole variety of ways to learn about it without AXFR.
For what it's worth, I would not flag a customer for running SSH on port 22; I would certainly flag a customer for having port 22 exposed where it didn't need to be; for most SaaS/ASP-type companies, I'd flag them for having more than one SSH port exposed, and I'd recommend that they invest in a VPN instead of exposed SSH.
I think there are far more nameservers allowing AXFR than you think. Write a little app that attempts a zone transfer for the top 1000 of the Alexa list (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and see for yourself. (Note to anyone reading: Please don't try this before you've checked if it's legal in your state/country or not.)
Could you explain how you would learn about wide-open-dev-machine as simply as by using AXFR in your scenario (you aren't on the network, so no *casting).
Edit: "so what possible reason could there be for enabling it?" is eerily similar to my message :)
4.8%. That's more than I would have thought, but it's still a small number: 95.2% of the Alexa 1000 keep AXFR disabled. Also: someone should tell some of these people not to do this.
Indeed. Keep in mind it's the top, so these are the people you really expect to keep something like that hidden. I promise you the stats are much worse further down the list, or if you do the same, but for a specific country's TLD.
Any reasonable password algorithm will have a unique salt for each password (well, a random long salt; you're highly unlikely to have collisions). Dictionary attacks still work.
Right. The analogy isn't bulletproof, but in conclusion it's pretty dumb to share information that could conceivably be used to extract some information or otherwise get an advantage when there's no reason to.
It was a kind of tongue-in-cheek comment to demonstrate the irony of "exposing it doesn't matter". I should probably have been more clear that I wasn't actually serious.
People should use proven KDFs for password authentication, not implement their own (including using my SHA-salting/iteration examples.)
Edit: removed "in web apps"