pmylund

Disclosure: I work for Evidon.

Evidon provides reports to different types of companies that give them information about what trackers appear where, how prevalent they are and/or whether they're in compliance with privacy laws. High-level reports, not "your data."

pokoleo forgot to mention that 1. GhostRank, the feedback feature of Ghostery, is very explicitly opt-in: no data is collected unless you enable it, and 2. We anonymize all of the data that's collected. We have no interest in tracking individual GhostRank users. What's interesting to us is being able to say "This tracker appears on the most websites, or causes the biggest slow-down of a page load on average."

More details here:

- http://purplebox.ghostery.com/?p=1016023438

- http://www.ghostery.com/faq#q14

And here's why: http://stackoverflow.com/a/5411601/620239. Forgot to change that first occurrence after pasting it in. "Oh, it works. I'm done."

And Go lets you do that. You just return the error.

Try writing a few things in Go. I very much doubt you'll respond like this afterwards.

Nice save.

Famous last words :)

Thanks for this example.

I wasn't trying to be condescending when I asked how it was significant. I really didn't understand what you meant.

I've added a note to the article.

Nm. Got it.

It's not that the size doesn't matter; it's just that it's not as significant. It becomes very, very hard to compute rainbow tables after just a few random bytes. No matter how long the salt is, it doesn't do anything to prevent somebody from trying to guess the original input for a given digest using a brute force approach, though. So usually the salt has less than e.g. 256 bits of entropy just because it takes up less space.

Sure, a very large salt might slow down the first iteration a little (but not necessarily subsequent ones, and it wouldn't require more memory, at least with most hash functions), so you're almost always better off just stretching the key--then you save the storage costs too.

How does this matter given a proper avalanche effect?

I agree, but "outsourcing" includes using libraries written by people who know what they're doing. (And not using libraries written by people who know what they're doing, but which are the wrong tools for the job.)

Sure, but I try to not make any assumptions without being boring. I think the goto-link at the beginning works fairly well.

OpenID and OAuth really did a lot, but there's just nothing called "don't use passwords." Fingerprint readers suck. Anything biometric that doesn't suck costs too much, and 99% of people don't have them. A good KDF is not bad in comparison to a centralized authentication server considering other factors.

Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrectly.

So something like a HMAC digest generated using a pepper stored in the source code/binary or on disk before passing it to bcrypt/scrypt? :)

This only really protects against SQL injection attacks, though/when there is actually a separation between where you store the bcrypt digests and where you store the pepper. (Granted, there are a lot of SQL injection attacks.)

You're right. That was an unfortunate choice of words.

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.)

Edit: removed "in web apps"

So much for white-boarding it. Fixed, thanks.

FWIW I included scrypt :)

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. 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.

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 :)

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).

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?

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.

Good point. Let's say, for the sake of argument, that each of them have their own salt :)

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.