Coda Hale's article ["How To Safely Store a Password"](http://codahale.com/how-to-safely-store-a-password/) claims that:

> 
> bcrypt has salts built-in to prevent rainbow table attacks.
> 
> 
> 

He cites [this paper](http://www.usenix.org/events/usenix99/provos/provos_html/node6.html#SECTION00051000000000000000), which says that in OpenBSD's implementation of `bcrypt`:

> 
> OpenBSD generates the 128-bit bcrypt salt from an arcfour
> (arc4random(3)) key stream, seeded with random data the kernel
> collects from device timings.
> 
> 
> 

I don't understand how this can work. In my conception of a salt:

* It needs to be different for each stored password, so that a separate rainbow table would have to be generated for each
* It needs to be stored somewhere so that it's repeatable: when a user tries to log in, we take their password attempt, repeat the same salt-and-hash procedure we did when we originally stored their password, and compare

When I'm using Devise (a Rails login manager) with bcrypt, there is no salt column in the database, so I'm confused. If the salt is random and not stored anywhere, how can we reliably repeat the hashing process?

In short, **how can bcrypt have built-in salts**?