People use IE6 because of external forces. You can add longer passwords to your application and still make it work with IE6.

Some do, some don't. I remember a digg survey a while back - a significant number responded that they had not upgraded because they felt no need to.

So just drop IE6 support - those people will soon wake up. But that has its own problems. If 10% of my users use IE6, and I drop support for it, that could have a significant effect on conversion rates and the like. Those people are going to do something else, maybe even go to a competitor.

The same applies to passwords. If, say, tumblr suddenly required 12 character passwords, then it would be quite a hit to their signup rates. This is simply not going to fly when there exists far less drastic measures (i.e. scrypt).

> How the hell are we going to get them to use longer passwords, and change them every year?

You merely require them to use longer passwords, and require them to change them every year. My university does this. They require a minimum of 8 characters, and they require that we change our password every 3 months or we can't log in.

If I had to come up with a new long password every three months I'd do what undoubtedly countless other people would do in the same situation: I'd write down my password somewhere nearby the computer so I could look it up when I needed it.

Overly onerous password requirements reach a point where they no longer increase security, they just shift vulnerability to a new area. They also piss off users.

If I had to change my password every three months, I'd do something even simpler: I'd stop using the service.

How many people do things like changing their password from "soccer5" to "soccer6" every three months?

That's avoided by not allowing more than three consecutive characters from the old password to be in the new password. It gets really annoying, trust me.

That would mean that they're storing the passwords themselves, hopefully encrypted, rather than just a salted slow hash of them. That makes me nervous. Should it?

you could have a form asking for the previous password and the new password... It then checks the previous password against the salted hash and then has the information to compare changes between the old password and new password without having to store anything

Then you[1] can just alternate between two sequences of passwords: password1, cleverme1, password2, cleverme2, ...

[1] Meaning: anyone who wishes to use the service but isn't willing to come up with an unending stream of genuinely different passwords for it.