Question- If are storing passwords in encrypted format in DB and in future when user login into our website how will we perform authentication?
You never, ever store passwords encrypted. Never. Under no circumstance. Ever. Do not store passwords encrypted. Do not even consider it, not even as an exercise.
You should only store passwords salted, possibly peppered, and hashed with a modern, secure, peer-reviewed, cryptographically sound password hashing function / password-based key derivation function / password-based key stretching function.
Me:-we will first first encrypt the password using same hash function then compare it with already stored password.
This sounds confused. You are talking about "encrypting" using a hash function. That makes no sense. You cannot encrypt with a hash function, you can only encrypt with an encryption function. With a hash function, you can only hash, not encrypt.
Interviewer:- But if someone breaks into our system and find out our hash function which is same for all then he can easily access customer's password.
This is, dare I say, BS. Hash functions cannot be reversed, because of the pigeonhole principle. The basic properties of a modern password hashing function are
- pre-image resistance: it should be hard to find an input for a given output
- second pre-image resistance: it should be hard to find an input that produces the same output as another given input
- collision resistance: it should be hard to find two inputs that produce the same output
- chosen-prefix collision resistance: if I have two inputs, it should be hard to find a way to modify those inputs such that they produce the same output
- resistance against length extension attacks: a length extension attack allows an attacker to compute hash(message1 + message2) by knowing only hash(message1) and length(message1) for any message2 of their choosing, in other words, an attacker can concatenate arbitrary data to the end of the message and compute the new hash without knowing the original message
- pseudo-randomness: it should be hard to distinguish a pseudo-random number generator based on the hash function from a true random number generator
- avalanche property: any change to one bit of the input should change each output bit with 50% probability
- slow, and impossible to speed up using hardware, software, GPU, ASIC, FPGA, memory, and parallelism
Me-: We can create a hash function based on User-id. So everytime we are not using same hash function.
This is functionally equivalent to a salt, except much more complicated.
Interviewer- But this means app knows the user original password which is against User Privacy , even the app should not be know user's password.
This makes no sense. It requires knowing the User ID, not the password.
Anyone here knows the solution of this question?
The correct solution is to not use encryption. The correct solution is to store the password salted, possibly peppered, and hashed with a password hashing function such as Argon2id, Catena, Lyra2, yescrypt, or Makwa.