"As for password hashes, what do you mean by requesting a copy of yours? You can produce it if you knew the hashing algorithm of the website." Well, that's assuming website tells you what algorithm they use. Knowing your hash can tell you if they use a good algorithm, if they use salt, and even the number of iterations with algorithm like bcrypt

@Pharap actually, hashing is usually done in server-side, ssl being good enough to protect from man in the middle. also, javascript is quite bad for hashing things

@user352 Hashing client side does NOT increase security, even if it doesn't get intercepted. The server cannot rely on any hash the client computed for authentication purposes alone, thus negating any benefit of hashing client side.

Could it be argued that if the password is stored in plain text then it would be considered personal data? If I have a cat named Gustav who is born in 2013 and my password is "GustavMyCat2013" and it is not hashed I would argue that it is pretty personal. A password hash or plain text password would be needed in my opinion although I am not a lawyer.

@user352 Hashing client-side turns the hash itself into the password, also make adding unique salt per user complicated (strict decrease in security). If MitMed then only the hash is needed to log in. Unless the website has some convoluted challenge-response protocol with anti-replay measure.

"You can produce it if you knew the hashing algorithm of the website." Assuming the website uses a good hashing algorithm and follows best practices concerning hashing and salting, that is, using a cryptographically random salt, then producing the same hash should impossible, even if the algorithm is known.

Technically speaking, wouldn't a password + salt hash be a unique identifier and thus subject to GPDR?

@ratchetfreak: Doing key stretching (which any decent password hashing scheme should be using nowadays) on the client side is actually a pretty good idea, since it offloads the computation cost to the client and makes the server-side authentication code less vulnerable to DoS attacks. You do need to re-hash the stretched password on the server (to ensure that a database compromise won't reveal anything that an attacker could use to log in), but the server-side hashing can be fast if the password has been pre-stretched on the client side.

"As for password hashes, what do you mean by requesting a copy of yours? You can produce it if you knew the hashing algorithm of the website." ... I can also reproduce my name or my passport number without needing to consult a database, but if they are collecting it then they had better include it in an info request. I'm not sure what your point is.

@DavidGrinberg GDPR yes. I actually had to read the thing a few times. But yes the user can request data for purpose of checking correctness so that incorrect or blatantly abusable data can be changed/deleted. Nowhere does it say you need to give the data as its stored in your database. So at the end of the day you can review your identifier data by logging in and change it by changing the password. Now i suppose this means GDPR actually forbids the company form making it impossible for you to change the password, also they can not share the hash. Then it has technical issues as a reason too.

@DavidGrinberg do common salting procedures actually guarantee uniqueness. Say mypassword+mysalt=myhash. Then yourpassword+yoursalt1=myhash (by chance). Is the procedure to try yoursalt2, yoursalt3, ..., until uniqueness achieved? I think hash collisions would be extremely rare. But would they actually be a problem when they happen?

@emory it would be incredibly rare (think likely never to happen in an applications life span), but if it ever did happen it wouldn't be a problem. All that matters is that my pass + salt = my hash