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