The 16-character limit is not as bothersome to me as the fact that they go out of their way to set onpaste="false" in their HTML, making even 16-character passwords annoying because the average user has to type it all in by hand.
I will never understand the rationale for preventing me from pasting a strong password versus picking a weaker password that I have to type by hand. Currently, my workaround is to use "Inspect Element" with a Web Developer Extension and remove this rather unfortunate attribute.
I know that password manager tools like KeePass can type in the password letter-by-letter (but then, why not just allow paste?), but this automation is normally designed for login screens, not for password change forms.
Rather than doing this by hand via Firebug/Chrome Inspect Element, it might be worth looking into creating a quick Chrome Extension or Firefox Add-On (or even a userscript) to do this for you.
I understand the initial rationale behind not allowing you to paste a password:
(1) Pasting a password can allow a malicious user to find your password somewhere and paste it in (as it would take much more time to type by hand).
This doesn't make any sense - as you pointed out, there are programmatic ways to avoid actually being unable to paste. Furthermore, a malicious user going through a password list would likely be using a command line interface or script, and not bothering with a GUI anyway. I'd call this issue completely moot.
(2) You could accidentally paste it somewhere else.
This has a little more value, but it doesn't come anywhere close to being a valid reason to disallow pasting. The security benefits of using a secure password manager (like KeePass or a TrueCrypt volume with a password list) are so much greater than Blizzard (or anyone) worrying about what you're going to do with your paste buffer.
The problem with putting any limitations on passwords that a user can use is that they almost always backfire. Sure, it might have made more sense when hashing algorithms crapped out after several characters, but in today's world those hashing algorithms shouldn't be used anyway.
(3) you type your intended password wrong, copy it, paste it, and lock yourself out. The sites make you type the password twice is to make sure you did it right. People who can't be bothered to type a password twice are probably heavily intersecting with people who didn't type it right the first time.
This seems somewhat contrived, but in realm of plausible, so let's say it's in the fact the reason for doing so. If so, why do you think that the old/current password field also has paste disabled?
I think an easy solution (that perhaps I just haven't found) in KeePass is to have a feature like "Perform Auto-Type" (which does the full login and password typing sequence), but for any arbitrary field. If I could find that, then this would be a moot issue for me.
Any password length limitation (within reason, not allowing a 1MB password is reasonable) says to me "we are not using hashes". That may or may not be the actual case, but it's the only reason I can think of for limiting password length. Hashes used for passwords have fixed lengths regardless of input, so any length password will "fit" in a database column.
If you're using hashes, limiting the lengths of passwords is extra work.
I'm not talking about Battle.net specifically. I'm talking about in general. That's merely the impression that a password length limit gives to me, on any site. Can you think of any another "rational" reason for limiting password length? I see two possibilities:
1. They're not using hashes.
2. They are using hashes, but they don't understand what that actually does, and that there's no reason to have a limit on input length. The passwords might be more secure, but it calls into question the general competency of their security (do they salt? per user?).
This also applies to character restrictions (no ____ characters). I can understand requiring at least N instances of a class of characters, but the entire UTF-8 character set should be valid input. If I want an emoji password, there's no reason to disallow it. bcrypt will be happy to take those bytes.
So, here's a comparison of site purposes and security practices. This is largely unrelated, but it gives better insight as to what I was talking about, not just making a random assumption about Battle.net (which I theoretically have an account at, but I don't really care about it anymore, I don't play video games anymore).
Chase is a bank. They handle money. They allow up to 32 character passwords, with no "special" (whatever that means) characters whatsoever.
Twitter is a social networking site. I have a 50 character password of various character types, because that's how far 1Password will go.
Bank of America is also a bank. Twenty characters. Twenty. Characters. And none of those are allowed to be "special".
Facebook is user for the same purpose Twitter. I have a 50 character password there as well.
Why do I trust social sites more than my banks? Security is so messed up.
If you are to abide by CWE-521: Weak Password Requirements. Then all passwords must have a min and max password length.
There are two reasons for this. For one, hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service. Especially if the server is using key stretching such as PBKDF2.
The other concerns is hash length-extension attacks or the prefixing attack against MD5. However If you are using a hash function that isn't broken, such as bcrypt or sha-256 and you aren't using an HMAC, then this shouldn't be a concern.
In general maybe but if you have safeguards in place such that 16 character passwords can't be bruteforced than you don't gain much by going to 256. Every hack/stolen account I've ever heard about was spoof login/keylogger/MITM, social or same p/w from another service that kept it in plaintext. I'd guess some people just got hacked because they use the most common p/w's ("12345678", etc.). 256 characters wouldn't help any of those people
