Your Systems Have a Bullseye on Them. Yes, Yours.

I know what you're thinking: why would the world's hackers want to hack my Internet service?

Your service isn't interesting, right? Even if your database is hacked, you don't have anything damaging--or anything hackers else would want--right?

Wrong. If you run a app or website with a multitude of users your database contains a pathway to people's email, bank accounts, medical records, and so on.

How? Passwords. You have people's passwords. Do you tell your users to not use the same password as they use elsewhere? Too bad, they do it anyhow.

Do you keep your passwords encrypted in your database? That doesn't help when a huge chunk of user passwords that are susceptible to simple dictionary attacks. No matter how strong your encryption, your data is still a gold mine for hackers, which means your site is a target.

The Solution is Simple: Pick Your User's Password For Them

The New Password Paradigm is simple: instead of asking a user for a password, you generate one for them and send it to them via email (yes, this Paradigm is not appropriate for email itself, obviously).

That way, your database only includes passwords that work on your service (and are thus useless everywhere else), meaning it's much more likely hackers will leave your service alone if you do not work with critical personal information (e.g. you run a blog, discussion forums, vanity app, utility, and so on).

It also means that your service cannot be broken into by hackers making use of known password databases

We have included a reference implementation as well as working example page in JavaScript and HTML.

The Old Way is Dangerous and Potentially Costly for You

Yes, this is a change in user behavior, and no, it's not as convenient as the old days when users could just remember their child's birthday and use that password to log on to every single thing they use.

But we all know that isn't realistic anymore, and Internet services are coming under increased scrutiny and have paid fines exceeding a billion dollars already.

How Is It Done?

The New Password Paradigm is simple: using the same mechanism you probably use already for "forgotten password" functionality, simply email your user an easy-to-remember, simple password that is randomly generated when they initiate your service, and allow them to generate subsequent passwords whenever they want (because they will forget more often since it's not the same password they use everywhere else).

To mitigate the extra step users need to take to get their password, the New Password Paradigm specifies easy-to-use and easy-to-remember passwords, which are forgiving and work well with most typical usage patterns (for example, all lower case and no special characters so it's to type into a mobile phone).

We've Done the Hard Part For You Already

If you already have some sort of "forgotten password" functionality, chances are you already have 90% of the code to implement New Password Paradigm.

Get started now: Here is some instructions and example code.