3 ms·

Password Hashing in the Browser

2 points by edent 10y ago

Freak_NL 10y ago
This is one of those ideas that a lot of inexperienced developers come up with at some point. I did it myself ten year ago (with SHA-256) for a simple home-brew website, and recently a colleague of mine brought it up. Sometimes the argument represents a holdover from pre-HTTPS times, and sometimes the reasoning is something along the lines that the user's password should be private. If you are developing (now, in 2016) a public HTTP API that allows logging in with a password, then you can simply discard the notion of not having a secured channel between the browser and the server. Of course you are using HTTPS, and of course you are securing your API in such a way that plain HTTP requests will fail. The second argument appears valid to some extent at first glance. Users tend to reuse passwords, despite being advised not to do so. But if you are the developer of the API, then why should you go out of your way to make sure the password never reaches your server at all? That is, you can (usually, if you have the necessary access clearance) already access all the data protected by that password! Furthermore, not seeing the password when it is being set by the user means a malicious/misguided user can simply work around your client-side minimum requirement checks, and send you a hash for '12345' (or do you want to maintain a database of all possible hashed representations of passwords containing less than the minimum required character count?). As a developer you hash passwords, and never store the plaintext password anyway. Check that it is not getting logged anywhere (so always HTTP POST passwords, never GET). You provide only HTTPS (assuming this is a public API). If you need more security, use two-factor authentication. As a user you should assume that a password is a shared secret between you and the service you secure with it. Assume that the service could store it plaintext, and that malicious employees of that service could try to gain access to any other service you use. In short, use a password manager and do not reuse passwords for anything you care about.

2 points by edent 10y ago

This is one of those ideas that a lot of inexperienced developers come up with at some point. I did it myself ten year ago (with SHA-256) for a simple home-brew website, and recently a colleague of mine brought it up. Sometimes the argument represents a holdover from pre-HTTPS times, and sometimes the reasoning is something along the lines that the user's password should be private. If you are developing (now, in 2016) a public HTTP API that allows logging in with a password, then you can simply discard the notion of not having a secured channel between the browser and the server. Of course you are using HTTPS, and of course you are securing your API in such a way that plain HTTP requests will fail. The second argument appears valid to some extent at first glance. Users tend to reuse passwords, despite being advised not to do so. But if you are the developer of the API, then why should you go out of your way to make sure the password never reaches your server at all? That is, you can (usually, if you have the necessary access clearance) already access all the data protected by that password! Furthermore, not seeing the password when it is being set by the user means a malicious/misguided user can simply work around your client-side minimum requirement checks, and send you a hash for '12345' (or do you want to maintain a database of all possible hashed representations of passwords containing less than the minimum required character count?). As a developer you hash passwords, and never store the plaintext password anyway. Check that it is not getting logged anywhere (so always HTTP POST passwords, never GET). You provide only HTTPS (assuming this is a public API). If you need more security, use two-factor authentication. As a user you should assume that a password is a shared secret between you and the service you secure with it. Assume that the service could store it plaintext, and that malicious employees of that service could try to gain access to any other service you use. In short, use a password manager and do not reuse passwords for anything you care about.