Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I am writing a webpage on which a user can set (when registering) and change his/her password. This page is only served over HTTPS. When the user is altering his/her password, he/she is already authenticated with his/her current password.
I am planning to use bcrypt to encrypt and salt the password. Should this be done client-side (browser) or at the server? In case of client-side, I could verify on the server that bcrypt was applied with at least X (for example, 12) iterations.
Normally password hashing is done server side. It doesn't need to be, but if you use client-side password stretching there are a few things to be concerned about.
Some people also add "A password hash is password-equivalent so client side hashing adds no security at all." This is good advice for people that think password hashing is an alternative to authenticated encryption (it isn't) but often people mistakenly use it as an argument to not do client side password-stretching. It's a bad argument because client- or server-side, you're still vulnerable to eavesdropping if you don't use encryption
One major advantage to client-side hashing is that it takes the burden of password stretching away from the server. To validate passwords the server needs to stretch every password submission it gets. (Ignoring successful brute-force prevention.) This could be exploited for a denial of service attack.
For desktop applications I might recommend client side hashing. (With end-to-end encryption with pinned server keys.)
If you use client-side password stretching then you SHOULD NOT store raw password hashes in your database. This would let anyone who stole a password-hash database to log in as any user without determining what their password was. Instead store a hash of the hash. As in something like $\text{SHA-512}(\text{bccrypt}(password, salt))$.
(Bcrypt would be done client-side and SHA-2 server-side. Normally plain-old-hashing of passwords is not secure, but hashing the hash is okay because the input has already been salted and stretched. People won't bypass the bcrypt part and go directly to searching for SHA-2 preimages because finding preimages would be a waste of time compared to guessing and hashing passwords.)
You said:
I could verify on the server that bcrypt was applied with at least X (for example, 12) iterations.
Which leads me to believe you're misunderstanding something. It sounds like you want to hash both client-side and server-side.
First, that isn't possible unless you also have the original (plaintext) password. Second, that is a waste of effort, assuming you're testing $H(p) == H(p)$ not $H(H(p)) == \text{StoredHash}$. (The latter being splitting hash-stretching work between client and server. The former being redundant because both client and server do the same work.)
To verify that enough bcrypt rounds were used you only need to password-hash (using bcrypt) each new password once. Just hash the plaintext password server-side whenever an account's password is changed with the appropriate parameters. Then save that hash to use for password verification from that point on, for the remaining lifespan of that password.
Lastly, I think I should recommend against client-side hashing. Not because it's inherently bad, but because I think server-side hashing will be safer and easier to implement.
You also should be using argon2, which is designed to be costly by requiring both CPU and RAM resources. bcrypt requires small amounts of RAM and it's cost parameter is only used to alter CPU time. argon2 was the winner of the password hashing competition.
If you're using PHP consider using the built-in password hashing API, whether you use bcrypt or argon2. It supports both algorithms, takes care of salt generation for you, and is a very simple API.
