Skip to main content
Information Security

Return to Answer

added 367 characters in body
Source Link
Hayley
Hayley
  • 49
  • 2
  1. Add atwo new columns, a salt column, and a new hash column, initially null.
  2. When an authentication request comes in, check the salt field.
  3. If the field has a value then thisthere is a new-style hash that has pepper and salt added. Handle accordingly.
  4. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute and store a new-style hash and. The legacy system won't know to do any of this, so only the new system can replacedo it. (It would have been better if neither system had to deal with it but could delegate the job to the database itself. The new system can, the old onesystem can't.)

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are the onesthose who never use the system anyway and wouldn't notice being locked outlog in at all. Either way,

Putting the old-style hash supportunsalted and transitional code cansalted hashes right next to each other in the table just illustrates the fact that for as long as the legacy system continues to be removed (e.g.used, declaring the salt field NOT NULL)use of best practices in the new system will continue to be irrelevant from the standpoint of security.

  1. Add a new salt column, initially null.
  2. When an authentication request comes in, check the salt field.
  3. If the field has a value then this is a new-style hash that has pepper and salt added. Handle accordingly.
  4. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute a new-style hash and can replace the old one.

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are the ones who never use the system anyway and wouldn't notice being locked out. Either way, the old-style hash support and transitional code can be removed (e.g., declaring the salt field NOT NULL).

  1. Add two new columns, a salt column, and a new hash column, initially null.
  2. When an authentication request comes in, check the salt field.
  3. If the field has a value then there is a new-style hash that has pepper and salt added. Handle accordingly.
  4. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute and store a new-style hash. The legacy system won't know to do any of this, so only the new system can do it. (It would have been better if neither system had to deal with it but could delegate the job to the database itself. The new system can, the old system can't.)

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are those who never log in at all.

Putting the unsalted and salted hashes right next to each other in the table just illustrates the fact that for as long as the legacy system continues to be used, the use of best practices in the new system will continue to be irrelevant from the standpoint of security.

Source Link
Hayley
Hayley
  • 49
  • 2

  1. Add a new salt column, initially null.
  2. When an authentication request comes in, check the salt field.
  3. If the field has a value then this is a new-style hash that has pepper and salt added. Handle accordingly.
  4. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute a new-style hash and can replace the old one.

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are the ones who never use the system anyway and wouldn't notice being locked out. Either way, the old-style hash support and transitional code can be removed (e.g., declaring the salt field NOT NULL).