Given that practically every non-financial protected website I frequent offers password recovery or reset via email (forget your password?), I don't think passwords are even necessary for these sites. A time-limited security token issued through weekly or monthly email containing a URL with one-time password effectively removes the need for passwords.

I am calling it mail-in authentication for lack of a better name. The intention is to replace those 'signin' and 'login' buttons with 'mail-in' buttons and remove the password field.

This is how mail-in authentication would work from user experience point of view:

1. User registers at the site by entering an email address.
2. User opens the email and clicks on the authentication link.
3. Site issues a time-limited token cookie containing user and device identity hints. User is signed in at this point.
4. Next time User visits the Site, user signs-in automatically unless the token is bad or lost.
5. When the token is not accepted for whatever reason (expired, failed validation, flagged as being used in a replay attack elsewhere, deleted, or roaming), User is returned to step 1.

Note that there is one password still needed, the one used to access email. That's where Kinda comes from. In this scheme, email password becomes the universal password of sort.

While I don't recommend this authentication scheme for web applications with medium to high security needs, I think it's acceptable for low level security needs. To meet roaming requirements, temporary session token can be issued automatically when access from an unknown device is detected.

Update:

Paul Madsen points out that latency, spam (more specifically chance of getting past spam filter), privacy concerns (giving out email) could make mail-in authentication unusable. Those are valid points but I've got a trick up my sleeve that'll cover those. I am just not ready to share it yet cuz I want to validate the UX flow with a prototype.