2

Recently In an interview I was asked this question - Question- If are storing passwords in encrypted format in DB and in future when user login into our website how will we perform authentication?

Me:-we will first first encrypt the password using same hash function then compare it with already stored password.

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.

Me-: We can create a hash function based on User-id. So everytime we are not using same hash function.

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.

Me- I don't know :(

Interviewer- Rejected!!!

Anyone here knows the solution of this question?

4
  • 6
    Well, we cannot read the mind of that interviewer, but it is practically infeasible to reconstruct a (valid) password for a hash value when using a cryptographic hash function.
    – Doc Brown
    Commented Mar 21, 2021 at 15:59
  • 1
    In a truly secure system, it doesn't matter if the attacker knows the hash function. “The enemy knows the system” is Shannon's Maxim, a variant of Kerckhoff's Principle. In your suggestion, you'd need already know the plaintext password in order to select the correct hash function which is fairly secure. But in practice, cryptographic salts are used instead. They make cracking the hash much more expensive.
    – amon
    Commented Mar 21, 2021 at 16:39
  • 2
    Encrypted and hashed are not the same thing. Are you using the two terms interchangeably?
    – whatsisname
    Commented Mar 22, 2021 at 3:52
  • hashing passwords is not good enough. the passwords should better be encrypted asymmetricly
    – OhadR
    Commented Mar 31, 2021 at 13:41

4 Answers 4

Reset to default
8

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
  • memory-hard

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.

1
  • Just wonderin' ... so dev would already fail your interview if he sloppily used "... encrypt ... using ... hash function ..."? :-)
    – Martin Ba
    Commented Mar 22, 2021 at 16:19
6

I don't know whether the interviewer asked something wrong on purpose to see whether you would correct him or he was just simply wrong. But when you used a hash function if someone breaks into the system and find out the hash function then they cannot access the customers' passwords. Encryption is a reversible encoding hashing is not reversible.

The first answer you gave is partially correct, but you used the word encrypt, maybe the interviewer guessed that you didn't know that hashing and encrypting are not the same thing. It would have be pedantic, but correct to say that the first time you generate the hash from the password and you store it into the DB, then to check the password you repeat the hashing function and you check whether it produced the same string that was stored. For what matters password reversible encryption should not be used.

0

If you are storing passwords, encrypted or not, you are doing something wrong. You should see if you can’t get your organization to prioritize this and fix it.

In more traditional usage, where the password isn’t kept, you store a hash in the database, and it is this hash that you should be looking for. The hash is created from the password, and either a salt or a salt and pepper, using a cryptographically secure hash.

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.

No, we assume as a given that the attacker knows what hash we are using, that doesn’t allow them access to the password, because it’s a one way hash. The part that knows the password, returns a hash and then forgets about the password (possibly even taking steps to destroy it in memory)

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.

Depending upon how you look at it, it is impossible to avoid at least some part of the application from knowing the password. But with a good design that part of the application isn’t the part that knows what user is associated with it, and it should never persist the password. The part of the application that deals with retrieving the user should be passed the hash, and use the hash and the user ID for retrieval and validation.

Interviewer- Rejected!!!

Is what they don’t say after you have explained this.

0

The interviewer bamboozled you.

First, as Jörg W Mittag has said, hashing is not encrypting. Mixing the two up only confuses things.

Second, the interviewer told you that the password needs to be stored in the app, which is against the company policy. That was a trick - the password never needs to be stored anywhere. You take the password, hash it, then throw the password away.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.