79370143

Date: 2025-01-20 02:13:25
Score: 2
Natty:
Report link

Unless you have a very, very convincing reason to do so, passwords should never be sent back from an API endpoint, should never be decrypted, should never leave the database.

Using bcrypt as an example (since you mentioned it), a standard email/password authentication would roughly go:

  1. User creates account: the database ensures the email address is unique. The password is bcrypt hashed and stored. This is one-way hashing - information is lost in creating the hash, so it cannot be decrypted.*
  2. User logs in: they POST their email/password to the backend. The database looks up the user by email. The backend then bcrypt hashes the supplied password and checks if it matches the saved hashed password for that user. At no point is anything here decrypted or sent back.
  3. The user forgets their password: The user must reset their password via verified email. I'm assuming you've had to do this at some point - the reason almost all sites require a password reset, is a correctly stored, strong password CANNOT be recovered, not even by someone with database access.

There should only be three times that column is ever hit in the DB - creating an account, logging in with password, and resetting a password.

With all that in mind, is there any convincing reason your app needs such a massive security vulnerability? If there isn't, problem solved - you don't need to decrypt anything, the password column won't even be in your queries, and there shouldn't be any search slowdown.

* edit: technically it can still be cracked in other ways, but assuming a strong password, this needs an unrealistic amount of compute power/time

Reasons:
  • Blacklisted phrase (1): is there any
  • Long answer (-1):
  • No code block (0.5):
  • Contains question mark (0.5):
  • Low reputation (1):
Posted by: ooshp