Documentation is unclear about Sorcery's salt being entirely separate from the one generated by BCrypt #217
Description
As discussed here, the string that BCrypt returns when you encrypt the user's password for the first time is a concatenation of the BCrypt version, cost, salt, and checksum. When I decided to switch the project I was working on from Devise to Sorcery, I figured that I could just split the :encrypted_password field of my User model into :crypted_password and :salt in a migration, on the mistaken assumption that the :salt field of Sorcery's User model was the same salt that forms the first 29 characters of :encrypted_password.
From what I can tell, BCrypt is unique among the currently supported encryption providers in this regard. I also notice that one of the planned features for sorcery is storing the salt and hashed password both in the same field. Implementing that for all other providers would probably be the most straightforward way of addressing the problem, but it leaves open the question of what to do with currently existing salts. Maybe there should be a config option to have a separately stored salt for backwards compatibility, along with documentation explaining this?