1

I know there are many questions about hashing passwords on the client side out there, but none of them, which I found, address my use case.

My app will be end-to-end-encrypted and it is not an option to send the actual user password to my server. I have to hash the password on client side.

After hours of research I decided to use PBKDF2 with SHA256, but I am confused. It seems that PBKDF2 needs a salt.

I want to use the implementations from crypto-js, because I did not find other implementations for PBKDF2.

How should I generate the salt for PBKDF2? The resulting hash has to be the same for every run, because it will be the users password from the application servers perspective.

Could you additionally provide some reference code or project, where this is being done?

(The hashing is not intended to prevent MITM, but to prevent my application from knowing the password at any moment.)

Thanks in advance.

Context (as suggested by @Daisetsu)

This should be an application where small teams can store credentials, for example for network switches. All data should be end-to-end encrypted, so that companies can trust the application and even hacking the application server does not give sensitive information.

Because some users might set the same password for authentication and encryption their private keys (which I think every user will do), my server normally would be able to decrypt the private keys as the user logs in. To prevent this, it has to be hashed by the client.

The Javascript cannot be trusted, but I could make a zip containing all files and you could run the angular app locally against my REST API ;)

Improve this question
3
  • Is there a particular reason you're worried about your application potentially knowing the user password before it hashes it server side? If you can't trust your application, then what makes you trust the javascript it's serving? Do you just want to do this for 'cool points', or to be 'extra secure'? Please update your question with context on what kind of attack you're trying to prevent against and by whom. Knowing the scope will help create a better answer.
    – Daisetsu
    Commented Apr 24, 2016 at 19:30
  • Context added ;)
    – Hendrik
    Commented Apr 24, 2016 at 19:43
  • Here is what I am planning to do after chatting with Daisetsu: I hash the username with something like SHA256 and use this as the salt for PBKDF2+SHA256 to actually hash the password. Many thanks to Daisetsu!
    – Hendrik
    Commented Apr 24, 2016 at 20:57

1 Answer 1

Reset to default
0

As I mentioned in the comment, you can't trust javascript served by the server. The idea of keeping the client side downloaded on their computers is interesting, although that doesn't really solve the issue. The server can still include javascript as part of a response unless you are insanely careful. In this case I really wouldn't go with javascript. There's just too many ways it could go wrong.

My recommendation in this case would be to use a browser plugin, or some other client side application which could be compiled and signed since you're dealing with sensitive credentials. Is there any reason you couldn't just go with a service like lastpass? Why reinvent the wheel.

EDIT:

How to implement crypto-js PBKDF2 with salt https://stackoverflow.com/questions/22875419/cryptojs-how-to-generate-aes-passphrase

You also mentioned that you think the users will reuse their passwords in both your system login and their private keys. After the user submits their keys/certs to the system, you may want to look into auditing their uploaded creds by using the password they supplied to unlock the cert/private keys.

Improve this answer
8
  • Sorry, but this does not answer my question at all... Accept that I really want to hash it. I simply can not find a solution for this, because everyone says, that it would not be needed. Leave Javascript out, theoretical I could setup the client to only and only consume the rest api. I despair not finding a solution at all... ;(
    – Hendrik
    Commented Apr 24, 2016 at 19:56
  • Hm, I see what you mean. I'll edit my answer. It's up to you in the end. It's your project.
    – Daisetsu
    Commented Apr 24, 2016 at 19:57
  • Sorry, I'm pressing Enter way too often, so it saved the comment too quickly...
    – Hendrik
    Commented Apr 24, 2016 at 20:00
  • Updated my answer, and I included a suggestion about auditing the uploaded credentials at time of upload (when you still have their password, assuming you don't hash it client side).
    – Daisetsu
    Commented Apr 24, 2016 at 20:04
  • Thanks for your answer. This generates a random salt, but will this generate the same hash at each login? This would be necessary for the server to be able authenticate the user. (BTW: The asymmetric keys will be generated by the client. But I am not sure if two different passwords would make sense at user experience. Maybe I just use the same for both authentication and encryption.)
    – Hendrik
    Commented Apr 24, 2016 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .