Hi @Justin - thank you, and my apologies for delayed reply, I didn't see the reply before.

Would it be the case that possibly the easiest thing would be to just invalidate all current password fields and force returning users to create a new password, in effect switching them over to the Laravel auth system?

To be honest, I currently get very few "backend" logins from the information providers to update, as their info doesn't change much, and there's no login required for listeners.

The backend template is very basic (see below, I just knocked it up in Bootstrap 3 in 2014!) But it is accessible for screenreader users and any replacement needs to be, too. What do I need to add NOW to ensure painless growth? Spark? Nova? Lumen? They all look like candidates.

I think, in my mind, I've now made the decision to go Laravel. Just need a steer with the right plugins! Wish me luck! :)

I can't speak much to Spark or Nova as I've never really used them.

Nova is a spiffy package from the bit I've played with it. However, it seems to be more geared towards being an Admin panel, and doesn't look like it'd be a good fit for a user interface.

I haven't used Spark, but it looks to be geared towards billing and payments. If you take payments it might be a good time savings to just purchase Spark.

Lumen is mostly just Laravel Lite. Or Laravel Double-Speedy-Quick. It's a micro framework geared fully for speed, at the expense of some other niceties. For the most part, I feel Laravel is plenty fast, as long as it's set up right (good caching, no crazy queries, etc; things that can cause problems for any framework). If you do decide to go with Lumen, you can always convert your project to Laravel by dropping your Lumen files into a Laravel project.

As it relates to the easiest way to switch over passwords in a security conscious manner without modifying Laravel defaults, it's probably easier to generate the hash Laravel expects (defaults to Illuminate\Hashing\BcryptHasher.php) before switching to Laravel, and storing that in your database as a new, separate field. However, this would require that a user login during the period before you switch so you can generate the hash. If they didn't, they'd have to go through the password recovery process after the switch.

The alternative is to tell Laravel to hash the passwords the same way you do in your current system. If you're alright with using the default Laravel login system (ex password recovery), you can create a custom Hasher that would allow Laravel to use your existing password hashes. It may sound a bit intimidating, but it's really not too bad.

• Create a ServiceProvider for your own custom Hasher
• In the register method, extend Manager by calling Manager::extend();
  • The Manager extend will load up the customer Hasher you'll create
• Update config/hashing.php to tell Laravel to use your Hasher

The customer Hasher route is the way I'd go. If you want to phase it out later to be as Laravel-y as possible, you'll have more flexibility in time frame and how you want to go about it.

Thank you so much! And I think I'm already using bcrypt, because the previous "mini" MVC I was using has:

$user_password_hash = password_hash($_POST['user_password_new'], PASSWORD_DEFAULT, array('cost' => $hash_cost_factor));

And from http://php.net/manual/en/function.password-hash.php I see that would be producing bcrypt hashes.

So, all good!

Thanks!

If anyone else wants to chip in regarding the back end admin, then please do so!

If that’s the case, you may only need to update the ‘cost’ in the hashing config to match your current. :D