4

I don't want the password to be sent in clear text over the internet, even when using HTTPS the server admin can read the password if they somehow cache or log post requests.

Now, what I have come up with is the following.

First, generate a "salt" from the user email and extend it with padding like this:

var email = "example@example.com"
const padding = 0x12564213155763573 (this is constant for all users)

var extended = email.padEnd(100, padding) //appending the padding at the end of the email and maximum string length is 100

var salt = sha256(extended)

Then calculate a hash of the password using PBKDF2 like this:

var password = pbkdf2("user password", salt, 10000, 128)

The hashed password will be the actual password of the user, and it will be sent to the server and the server will calculate another hash of that hash.

I'm posting this here because I came up with this on my own and I feel like something is missing or wrong here, as they say about cryptography you shouldn't invent it yourself.

Are there any flaws in this system?

Note: The user password is used to encrypt user private data that should be only decrypted by that user.

Anders
  • 65,052
  • 24
  • 180
  • 218
  • 2
    If you're sending a hash of the password, that derived hash becomes the password-by-proxy. There are no additional security benefits; you're just adding a layer of obscurity... and since you're already using a key-stretching algorithm on the client side, you're probably making the developers feel like they can handle this derived hash as if it isn't the password, so it's _more_ likely to end up in logs or stored unmodified in a database. – Ghedipunk Nov 27 '19 at 19:21
  • @Ghedipunk, i forgot to mention that i use the user password to encrypt user private data that should be only seen by that user, so that would be a benefit. – noob-cryptor Nov 27 '19 at 20:07
  • If the password is used to derive a key to encrypt data, then you don't want that password sent to your server in any form. You want plausible deniability, where you can say that even if you wanted to look at their data, you can't, because the key or the material to derive it is never shared with you. – Ghedipunk Nov 27 '19 at 20:19
  • 2
    Possible duplicate of [Client side password hashing](https://security.stackexchange.com/questions/23006/client-side-password-hashing) – multithr3at3d Nov 27 '19 at 22:45
  • 1
    Welcome to the site! There is indeed no need for the server to ever see the password, so it's a good idea to do client-side hashing. Just make sure the server also does a quick hash to prevent the attack Ghedipunk mentioned. As for your design, it's alright but be aware that your magic padding does not actually increase the uniqueness of the salt and therefore has no benefits that I can see. The pbkdf2 cost factor can also be increased, 10 000 is not that much if I remember correctly (you should go as slow as is acceptable for your users). – Luc Nov 28 '19 at 09:50
  • Note that, because you didn't actually post a question (just "I'm open for discussions & ideas"), this is too broad and I have voted to close it as such. This Q&A site is for answerable questions, not open-ended discussions. If there is a specific question, you can edit your question. (Also after it has been closed, you can still edit and ask for it to be re-opened!) For the general case of a brief design review, see my other comment :) – Luc Nov 28 '19 at 09:52
  • @Luc Thank you for your response ! , first of all I'm sorry about not posting a real question, I'm new to this kind of sites, and for the server hashing, the server uses bcrypt to hash the client generated PBKDF2 – noob-cryptor Nov 28 '19 at 11:50
  • @multithr3at3d That question is about client side hashing without server side hashing. So I am not sure it is a duplibcate. – Anders Nov 28 '19 at 11:58
  • Admins can see it anyway. They are the admins! They can change the code to send them the cleartext of the password. You either trust them, or don't. If you don't, find some admins that you can trust. – ThoriumBR Nov 28 '19 at 15:20

0 Answers0