Not really. Even if you're worried about that, (36 alphanumeric + 10 symbols)^10 is roughly 4E16. Even at 2B checks/second/CPU (which is incredibly generous if the web developer has any competence) that's around 10M CPU-seconds, i.e. 115 CPU-days. For cracking one single password. An ASIC will speed it up, but again, remember this is one single password, and it can be an overestimate by like a factor of > 1 million if the developer actually used a KDF (and I'm not sure why they wouldn't, if they're already hashing). How paranoid do you have to be (and how big of a target do you have to have made of yourself? and exactly how valuable are your credentials?) to worry about a threat like this for most websites? Maybe it makes sense for your primary email, but do average accounts really benefit? Compared to the inconvenience of when something goes wrong and you have to type a long password manually.

If you don't let users use their preferred password structure, they'll have to use a shitty password like hunter2, letmein or dragon. Those can be recovered with a few attempts, even online. If you really want a 10 character password, you can hash the user's password, then imagine the first 10 bytes of the hash are the user's password, then do whatever you want with them.

How does one more iteration help? Your hash algorithm is already hashing multiple times. Seems it would be easier to increase the work input to PBKDF2 by 1 than to implement your own multi-hash. Even better increment it by 2000.

But the point is that you don't control the website's hashing algorithm, or whether they hash at all, or whether they store their hashes in a public s3 bucket. They may tell you what they do, they may not. But you have to trust them either way.

A long random password using a variety of characters is the only control I have when setting my password. If they have a good hashing system and protect their hashes, my long random password will not hurt anything. If they truncate my password before hashing, it will still be the best password I can make for that app.

If I use 5 5 letter words as my password and they truncate after the first 10, how would I know? My password might be "horseapple" instead of "horseapplehappygreennymph".

If I give them 10 alphanumerics and they leak their md5 hashes, I'm pwned in a few days, assuming they even salt it.

If I give them 20 random alphanumeric+symbol then I can't imagine what exotic thing they could do wrong to make it less safe than any other password I choose.

I might make an exception for some streaming service that I have to enter by hand on a tv remote control, but otherwise i am going to generate it with max entropy because I am never going to look at it anyway.

So long as passwords are unique, offline cracking isn't an issue. If they have that site's hashes presumably the site is compromised already.

Not true. Offline hacking is not only a concern for passwords used on multiple sites.

There are many scenarios where an attacker might be able to grab the hashes, but still need to crack them in order to get access to other data from your account. If there is a sql injection vulnerability in the authentication service, for example, it does not mean they can necessarily overwrite the hash or access data in other parts of the application.

I once found a bug in a payment processor that let me download the user record including password hash for all users in that payment processor. But I couldn't use that to get their stored credit card numbers directly. However, if I had brute forced those hashes, I would have been able to log in as them and access their other account data and make transfers, etc. I am sure a large majority of those password would have been very easy to crack. If I was an attacker, those would have been my first targets.