Let's say I've got a database of high-entropy credentials (e.g. 256-bit random values) used as API keys by clients. I'd like to hash them in my database so that a database compromise doesn't allow an attacker to access my API with stolen credentials.
Now, given that I have guaranteed high-entropy values (no short or easy to guess "passwords"), is there really an advantage to something like bcrypt? Could I do effectively just as well with, say, unsalted SHA256?
Yes. Salt is used to prevent precomputation attacks, but random 256 bit strings are too large for precomputation. Slow hash functions with many iterations are meant to slow down dictionary attacks, but random 256 bit strings are too big for a dictionary or for exhaustive testing. So a single SHA256 hash is secure for long, cryptographically secure random inputs.
I want to make a few points in addition to @NeilSmithline's excellent answer.
Taking a 256-bit random value and hashing it with SHA-256, the output will still have (roughly) 256 bits of entropy. I say "roughly" because it's an open problem whether SHA256 actually maps to every possible string on 256 bits - but for all practical purposes, it's close enough.
Bcrypt: the advantage of bcrypt is that it requires the attacker to do many rounds of hashing on each guess - thus slowing them down and driving up their electricity costs.
Brute-forcing: Let's say some fool wanted to try brute-forcing your SHA256'd 256-bit random strings. On average they would have to make 2255 guesses. Assuming each guess took 1 nanosecond and consumed one electron's worth of energy, it would take 1060 years (which is 1050 * ageOfUniverse) and would require a powerplant that consumes the energy equivalent of 9,000 Milky Way galaxies. 2256 is a big number.
Bottom line: So yeah, nobody's gonna go brute-forcing your 256-bit random values that you've run through unsalted SHA256, there's no reason to add extra computation in the form of bcrypt. Good on you for thinking about security and asking good questions :-)
(In reality, the weak link is your random number generator, not the hashing. If an attacker can narrow down the list of possible seeds for the RNG that generated those random values, then a dictionary attack might be possible. In that case bcrypt might add some useful slowdown.)
