Having hard time finding bcrypt this is it. How do I know Thats correct.
From the author's name (Niels Provos) in the comments, the file being in the BSD sources, as well as the explanation of how it works. This looks genuine.
It's not important that you use this particular scheme, you could as well use any of the others which are similar. What really matters is that you do not use any single iteration of a hash function, but a high number of iterations. Verifying a password must be slow.
Based on how much security margin you need and on how many server resources you are able (willing) to dedicate to this, anywhere from 5,000 to 100,000 iterations will do. It is a trade-off between how many logins per second your system can handle and between how much time you have to react when your database is compromised. Since you can't do millions of logins per second anyway (neither do you have that many users, nor will your database deliver that fast), it is usually entirely acceptable if you are able to handle a load of, say 100 per second. For a "normal sized" (that is, not the size of Facebook) service, this means that login is still "instantaneous" as perceived by the user.
See also the Wiki pages on bcrypt , scrypt, and pkbdf2 for further choices and info on the subject.
You might even implement this by hand. Usually, that is a "No, no, no!" thing, especially when one doesn't have a lot of experience with writing security related software. Insofar, think twice before diving into that. However, in this particular case, it is tempting because it allows for a low-overhead adaptive solution, and it is probably "allowable" since there is not so much one can do wrong. After all, it's just applying a for loop on a tested, established algorithm.
Technology gets cheaper and faster, and this is something you will inevitably have to deal with from time to time. As hardware gets cheaper and faster, the attacker's life becomes easier.
The nice thing about a "homebrew" build here is that all you need to do is store the number of iterations with each user name (since you need to somehow know that number) in your database. Now, whenever a user logs in, you do the hashing work to verify the password. You do that anyway, it's how the authentification works.
Since you have already done the work of hashing a thousand or so times, you can as well do yet one more hash (or another 3 or 5 if you want). That gives you a different hashed password with more iterations, but at basically zero cost. Store that new hashed password the database together with the new count (and a timestamp to give it an upper cap, like once per day or such, so a malicious user can't exploit this by logging in 10,000 times per day). Now your users' passwords will be rehashed regularly "for free", and the difficulty will slowly but steadily increase.
Alternatively, you can of course have a cron job run over the database once per month or so and rehash all passwords (that will also touch the ones who are never logging in), but then you need to explicitly do the number crunching, so it's not free.
