@jaheller Yes, definitely, I'm "sharing" bcrypt hashed passwords over multiple applications written in different languages.
The hash you are testing is invalid, it should begin with something like $2y$ (indicating the format used), not with $10$. The latter is the cost parameter that follows the format indicator prefix.
Whatever salt is used to calculate the password hash is stored with the hash in the string that you use. The string consists of the following parts:
- format indicator prefix (should be
$2y$ for bcrypt)
- the cost parameter used to slow down bcrypt, e.g. 10$
- 128 bits salt, 22 characters base 64 encoded
- 184 bits of the actual password hash calculated by bcrypt, 31 characters base 64 encoded
Example with my username (skliche) as the password:
$2y$10$G1FiMQnvTj09gfDcIb7SueRC9/ADDrEN85OBz03IHGMgDgZYLqTua
- format indicator prefix:
$2y$
- cost parameter:
10$
- salt:
G1FiMQnvTj09gfDcIb7Sue
- password hash:
RC9/ADDrEN85OBz03IHGMgDgZYLqTua
So the string in your database contains everything another compliant system needs to know in order to verify a password against the hash.
Try it:
password_verify('skliche', '$2y$10$G1FiMQnvTj09gfDcIb7SueRC9/ADDrEN85OBz03IHGMgDgZYLqTua');
That should work on your system as well.