1

Let's say Alice logged into https://www.facebook.com with her email and password:

Email: Alice@gmail.com

Password: correctHorseShoeBattery

Nonce given by the server: 123139897120148130481041

Salt given by the server: testafaaafadfm123

EXAMPLE of PBKDF2 Hash of password concat with nonce along with salt produced at client side browser: 570DE37EB907202E9C96F

My questions are

  1. Is the hash calculation of Alice's password concat with nonce & salt always performed at the client side?

  2. Wouldn't another person like Eve be able to use WireShark to sniff the hash value and re-use it in order to gain access? Or does having the nonce help to prevent that?

  3. Since it is HTTPS, is Eve still able to sniff it? As everything looks obfuscated, unlike HTTP where Eve can CTRL+F password field.

  4. Access would only be granted, if the hash value produced by the user == the hash stored in the server database. If So how can the server verify the PBKDF2 hash of (password concat nonce along with salt) when the server database at the time of Alice's registration only stores the hash of the password and salt at the time of registration? They simply won't match as the server hash does not have the nonce value.

I think I am missing something and can someone enlighten me, please. What is the industry standard and does what I have just described match the typical login process?

Killney
  • 373
  • 1
  • 3
  • 5
  • 5
    What you have described does not match the typical login process at all. Is this some specific system you want to implement? Or is it just how you understood normal password based login to work? – Anders May 17 '18 at 10:33
  • i see. so where can i read more on the normal password based login? Anything for me to read? – Killney May 17 '18 at 10:55
  • 1
    @Killney - the normal login process is to send username/password to the authentication server over HTTPS. If you hash the password client-side, all you do is make the **hash** the password. – Clockwork-Muse May 17 '18 at 14:31

0 Answers0