I'm curious why the passwords are set (seeded?) to time()
during the migration? That seems pretty insecure. The time of migration can be found in the columns that are set to Carbon::now()
in the same migration script, or it could be brute-forced pretty easily if you roughly know the week the migration took place on.
If the goal is to set a random unguessable password, PHP has much better methods to generate those. Or even better, leave the column empty so it won't be a valid hash and no passwords will match.
EDIT: after re-reading the code I realize the code might actually set the password to the bcrypt hash of the time, which stores a hash of a hash, so the hash that serves as password is in fact random since it contains the bcrypt salt which is a true random value. If that's the case then it's safe against attacks, but why do something so complicated to generate a random password? It's so slow compared to other options, there's no need to go through 10 rounds of bcrypt hashing if all you need is a random value.
The script ends up doing 2 times 10 rounds of bcrypt for each user, all of that to set an unusable password? This will waste a lot of minutes over a large dataset migration.