Has anyone got good, simple, Ember.js authentication examples where the app would send hashed + salted passwords to server?
It seems that all the examples I could find do not employ hashed + salted passwords. I.e. in these examples passwords are sent from Ember.js app to the server in plain text.
I’m not sure to understand, as the JavaScript code is readable, you can’t really hash your password client-side as you would need to expose the salt.
The way I’m doing is using HTTPS only, sending the password in clear text for registration, hashing it on server. Then my server never returns anything to the client (not even the hashed password), and only communicate to my API using an OAuth2 token (I really recommend you to use Ember-Simple-Auth for that).
That’s the simplest workflow.
Another thing I’ve done is used an intermediary server that just handles encryption and proxies the server requests for you. But @bakura is correct, you really can’t use a hashing mechanism client-side with any efficacy- just encrypt the communication channel. +1 for simple-auth also.
Thanks both. Yes I do plan to use HTTPS and a token after registration/login. However I still thought that sending password in the clear during sign-up/login isn’t good idea, even over HTTPS.
I used to implement hashed + salted password authentication for a native mobile app. Referencing on something like this: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ That’s why I asked the question.
After seeing your responses I did more research. Indeed it appears that plain text over HTTPS is the norm and considered secure enough. So I’ll go with that.
For future references though, I think there may still be cases when additional encryption/hashing is beneficial. There is a good discussion here, one of the linked youtube video is a presentation from OWASP and is eye-opening, titled “OWASP AppSecUSA 2012: Reverse Engineering Secure HTTP API’s With an SSL Proxy”.
You can use some asymmetric encryption and decryption (for example RSA). You give client public_key and encrypt the password with it and on server side you can decrypt it with servers secret_key that only server knows about.
Even though the password is being sent over HTTPS, it needs to be encrypted is what I think. To get a better idea of this practice I referred to this: OPAQUE: The Best Passwords Never Leave your Device
But, I also agree on the part of salts being exposed in this case we can use RSA encryption but doing it over a browser might be very costly. (I am not even sure if it is possible. Accessing RSA keys in frontend).