All you've done then is replaced the login process with the "forgot password" link. Every time this user logs in, you'll send him another random password, which he'll forget again immediately.

Worse, systems like yours usually ask for a new password when you log in again, but complain when the user supplies "password" or "letmein" because it doesn't have enough @ signs. And then it complains again when the user picks a password he's used before.

Maybe that's fine if you're a bank (though all it does is shift the plain-text password storage from your database to a sticky note on the front of your user's monitor), but if your site is just another URL shortener or whatever, I simply don't care how you store my password provided you can give it back to me intact when I ask for it.

Don't send them a random password. Send them a one-time login link (which is kind of like a random password, but it's embedded in the URL so you don't need to type it in to anything). The first screen they see once they're in asks them to reset their password.

For my own projects I don't set any limits on passwords that people enter - if they want to use an insecure password that's their problem.

I agree. That's the way forward.

A password that they can remember beats a password written on their monitor, even if it's not that strong.

how hard is it to program a "password strength" detector into these apps?