Skip to main content
added 4 characters in body
Source Link
Frank
  • 159
  • 5

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison.if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

added 341 characters in body
Source Link
Frank
  • 159
  • 5

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

deleted 50 characters in body
Source Link
Frank
  • 159
  • 5

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can replace the table with an insertable view orsomehow use pre-insert triggersthe db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can replace the table with an insertable view or use pre-insert triggers, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

added 2 characters in body
Source Link
Frank
  • 159
  • 5
Loading
edited body
Source Link
Frank
  • 159
  • 5
Loading
edited body
Source Link
Frank
  • 159
  • 5
Loading
added 5 characters in body
Source Link
Frank
  • 159
  • 5
Loading
added 200 characters in body
Source Link
Frank
  • 159
  • 5
Loading
added 25 characters in body
Source Link
Frank
  • 159
  • 5
Loading
Source Link
Frank
  • 159
  • 5
Loading