Does this really add anything to the seeding? You still have no way to know the password, and using bcrypt is just a good bit slower?

IMHO is a way to let the users know that they need to encrypt the passwords.

But if it's significantly slower then it's better not to merge this.

I also thought about pull requesting this to the user model:

    public function setPasswordAttribute($value)
    {
        if ( ! empty ($value))
        {
            $this->attributes['password'] = bcrypt($value);
        }
    }

But this would break compatibility with the current Reset Password feature (ResetsPasswords::resetPassword)

I also think the resetPasword callback should be in the PasswordController, since it contains app specific logic, similar to the AuthController::create method.

@sileence I also think the bcrypt call should be in the model #3236

I know this is old and closed but just noticed this change, it slows down tests a lot. I made this mistake on a project last January and it more than doubled the time it took to run our full test suite.

I would recommend using a precomputed hash if it really matters that it looks like a real password. Traditionally there's no reason to use random data in test factories, but I know lots of people reuse their factories for seed data in Laravel so it does provide some value, but for passwords, I don't think it provides any value even for seeds. Better to seed the same password for every test user IMO, both for speed and because you can then actually log in as different users in your development environment if needed.

Here's one for secret, which is a common sample password in Laraland:

$2y$10$oPCcCpaPQ69KQ1fdrAIL0eptYCcG/s/NmQZizJfVdB.QOXUn5mGE6

@adamwathan Thanks for this Adam. Hadn't even occurred to me that this would be the cause of my testing slowness. I had been using Codeception on projects before my current one, and there I generally had an sql dump which was imported before each test. But on my current project with some relatively complex user/role/permissions testing I'm on unit testing and model factories. A small group of 20 of my tests showed a speed bump from 17.41 seconds down to 3.35 seconds. That's a huge boost for my development process. The full test suite of 100+ tests goes from 2.7 minutes down to 1.7 minutes, but then I'm rarely running the entire suite, and usually it's a good time to go make a cuppa anyway ;)