This is insecure if LW1 hashes get leaked or were leaked at some point. If you know someone’s hash, you can login as them by making some JS changes in your browser. LW1 was secure w.r.t. that, because login required a plaintext password, and guessing it from a salted hash is hard even if you know the salt.
Other than that I don’t see any problems, but I know next to nothing about security :-/
This is insecure if LW1 hashes get leaked or were leaked at some point.
Isn’t this vulnerability inherent in the whole “hashing passwords on the client” setup? (indeed, it seems to miss the whole point of hashing?) Or am I misunderstanding what Meteor does?
I think this vulnerability is specific to Oliver’s scheme, not Meteor. What Meteor does is hash the password on the client (not sure why, might as well send it in plaintext over SSL) and then hash and salt it on the server as well (which is good and right).
This is insecure if LW1 hashes get leaked or were leaked at some point. If you know someone’s hash, you can login as them by making some JS changes in your browser. LW1 was secure w.r.t. that, because login required a plaintext password, and guessing it from a salted hash is hard even if you know the salt.
Other than that I don’t see any problems, but I know next to nothing about security :-/
Isn’t this vulnerability inherent in the whole “hashing passwords on the client” setup? (indeed, it seems to miss the whole point of hashing?) Or am I misunderstanding what Meteor does?
I think this vulnerability is specific to Oliver’s scheme, not Meteor. What Meteor does is hash the password on the client (not sure why, might as well send it in plaintext over SSL) and then hash and salt it on the server as well (which is good and right).
Yep, Meteor hashes twice. Not fully sure why. Probably to add an extra layer of security to non SSL connections.