From the paper:
> The server will restart periodically. All data kept in memory is lost at this point and the server must restart using only the data on disk – which is attacker visible.
So I guess your solution is correct and trivial but the author's solution doesn't use data from outside, not even a user provided symmetric key.
https://github.com/PolyPasswordHasher/PolyPasswordHasher#if-...
>provide enough passwords
Why don't they just store some dummy users' (with zero privileges) credentials directly on the hard drive? They simply can provide valid passwords from it after reboot and your attacker can have these passwords since they can't do anything with them. Maybe their leak strategy involves something like this?
The alternative solutions does not mention doing what you suggest, but reboots would be problematic. Of course you could do the same thing for bootstrapping as they do (leak a portion of the salted hash to disk and use that for verification), but that I'm pretty sure that allows probabalistic cracking of weak passwords (assuming most passwords are weak, the weakest password that matches is likely to be the password).
The advantage is that the administrator doesn't need to manually intervene, the disadvantage is that you can't verify passwords (in a way that is more secure than just verifying hashes) until you get at least K correct login attempts.
If the goal is only to defend against SQL injection, a much simpler solution is to just put the key outside the database, for instance in the configuration or source of the application.