Return to Answer

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

###WARNING! Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again this is a matter of convenience vs security trade-off.

Here is my feedback in more detail as an implementation. You may want to check it out.

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

WARNING!

Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again this is a matter of convenience vs security trade-off.

Here is my feedback in more detail as an implementation. You may want to check it out.

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

###WARNING! Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again this is a matter of convenience vs security trade-off.

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

###WARNING! Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again this is a matter of convenience vs security trade-off.

Here is my feedback in more detail as an implementation. You may want to check it out.

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

WARNING! Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again convenience vs security trade-off.

I recommend creating a static class named something like Hash, Crypto or Password depending on your project/context and making these methods public static, instead of making them private methods for the user class.

###WARNING! Unless your password encryption management code is sophisticated enough to manage password scheme versions and handle multi-version-migration complications PasswordHashWorkFactor should not be editable (i.e. by editing the relevant key in the config file). In that case, editing it would cause migration efforts or MORE IMPORTANTLY the attacker with R/W access to the config file can crash the system easily by adding an unnoticeable digit to PasswordHashWorkFactor (add a 0 to 100000). It would take significant time of the admin/dev to figure out the problem in a sophisticated config file while the users cannot log in. You may have it hardcoded as a const at the static class and change it in every major release at the code level. Again this is a matter of convenience vs security trade-off.