4 deleted 173 characters in body
source | link

This answer is different from the earlier questions that suggest you should hash the password, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

  1. Hash the real password twice using SHA256
  2. Hash the password once using RIPEMD-160 (to shorten it without truncation)

    You will have an output that looks like this 9c1185a5c5e9fc54612808977ee8f548b2258d31

    with BCrypt / Scrypt with a salt
  3. Send that hash to the back end as the user's password, and update it when the user changes their password.

  4. Use the same SHA256 / RIPEhash solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

This answer is different from the earlier questions that suggest you should hash the password, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

  1. Hash the real password twice using SHA256
  2. Hash the password once using RIPEMD-160 (to shorten it without truncation)

    You will have an output that looks like this 9c1185a5c5e9fc54612808977ee8f548b2258d31

  3. Send that hash to the back end as the user's password, and update it when the user changes their password.

  4. Use the same SHA256 / RIPE solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

This answer is different from the earlier questions that suggest you should hash the password, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

  1. Hash the password with BCrypt / Scrypt with a salt
  2. Send that hash to the back end as the user's password, and update it when the user changes their password.

  3. Use the same hash solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

3 added 120 characters in body
source | link

Where areThis answer is different from the earlier questions that suggest you usingshould hash the 3rd party API for authentication? Ifpassword, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

  1. Hash the real password twice using SHA256
  2. Hash the password once using RIPEMD-160 (to shorten it without truncation)

    You will have an output that looks like this 9c1185a5c5e9fc54612808977ee8f548b2258d31

  3. Send that hash to the back end as the user's password, and update it when the user changes their password.

  4. Use the same SHA256 / RIPE solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

Where are you using the 3rd party API for authentication? If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself.

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

This answer is different from the earlier questions that suggest you should hash the password, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

  1. Hash the real password twice using SHA256
  2. Hash the password once using RIPEMD-160 (to shorten it without truncation)

    You will have an output that looks like this 9c1185a5c5e9fc54612808977ee8f548b2258d31

  3. Send that hash to the back end as the user's password, and update it when the user changes their password.

  4. Use the same SHA256 / RIPE solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

2 added 120 characters in body
source | link

Where are you using the 3rd party API for authentication? If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself.

In other words, don't send the 3rd party API a clear text password, send them thea hash you create. Then Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

ThatThis approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

Where are you using the 3rd party API for authentication? If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself.

In other words, don't send the 3rd party API a clear text password, send them the hash. Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

That will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

Where are you using the 3rd party API for authentication? If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself.

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

1
source | link