Re: We are a part of the problem
support long strings (after all, why not in 2016? Don't tell me you can't afford the disc space any more)
There's no additional space requirement for (long) passphrases, compared to passwords, for most password/passphrase-based authentication systems, because they store constant-size hashes.
The chief obstacle to using passphrases is usability; total typing accuracy drops as the text gets longer (obviously), and anti-shoulder-surfing mechanisms (i.e., not displaying the passphrase as it's typed) make it hard for the user to note and correct errors.
Obscuring the typed passphrase can be dropped in some conditions, but the near ubiquity of cameras makes shoulder-surfing even more of a danger than it was when hidden input fields were introduced half a century ago.
The problem is compounded by lockout thresholds that are firmly stuck in the short-password era (locking out after three attempts or the like). Those policies are no longer very useful, particularly when password-strength requirements are enforced, but organizations cling to them.
My current work password is just shy of 40 characters, and I get it correct four times out of five - but when I get it wrong, I type it very carefully on the next attempt, because a lockout costs me time and effort (not to mention the aggravation).
A good approach would be: allow and require long passphrases; make the lockout threshold something reasonable, like 20 attempts; and let authentication succeed if the supplied value is close to the desired one.
The problem is implementing "close to" without keeping a copy of the plaintext passphrase. (It's straightforward if you do keep a copy - use weighted minimum edit distance and pick a threshold that doesn't reduce the entropy of a minimally-acceptable passphrase more than you're happy with.) It might be possible to do it with some geometric transformation of the passphrase1 without leaking an unacceptable amount of information to an attacker who gets a copy of the verifier, but I'm not offhand aware of any solution in this area.2
1Then compute the same transformation of the candidate, treat the two results as vectors, and calculate the angle between them. "Close enough" is determined by maximum acceptable angle. Converting that to effective bits of entropy in the passphrase is left as an exercise for the reader.
2Something coming out of the research in provable computation perhaps ... but now I'm just speculating idly.