The password hashing algorithm outlined is really not best practise, only 7 rounds and the use of SHA-256 which is a general cryptographic hash, not a password specific one.
The correct answer to password hashing is still mostly "just use bcrypt", or even better, scrypt or argon2. Failing that PBKDF2 with enough rounds is not terrible, if you have to. All of these algorithms should to be tuned to require as much processing power as you can afford.
I'm also a fan of storing another random value somewhere separate from the salt/password hash, which is incorporated into the hashing scheme. You might store the salt/password hash in the database, and the other random value on the application servers. This means if your database is compromised (i.e. though SQL injection), hashes can't be cracked without also compromising an application server.
The correct answer to password hashing is still mostly "just use bcrypt", or even better, scrypt or argon2. Failing that PBKDF2 with enough rounds is not terrible, if you have to. All of these algorithms should to be tuned to require as much processing power as you can afford.
I'm also a fan of storing another random value somewhere separate from the salt/password hash, which is incorporated into the hashing scheme. You might store the salt/password hash in the database, and the other random value on the application servers. This means if your database is compromised (i.e. though SQL injection), hashes can't be cracked without also compromising an application server.