As an aside, it's possible to modify Laurikari's algorithm slightly and obtain PCRE semantics w.r.t. capturing groups, and those correctly. (POSIX capturing semantics are designed for standards specs. I've never met an actual practicing programmer who wanted those semantics instead of the PCRE ones)
That's good to know. Is there an implementation of it? I know of TRE, regex-tdfa, ocaml-regex-tfa, and re2c, they all implement Laurikari's algorithm (or a variation of it), but have POSIX semantics.
Well, first off you make this (USE UNIQUE PASSWORDS) part of orientation, and maybe have part of orientation involve rolling dice and using the diceware list.
Then, you reinforce that by using some sort of SSO setup/service (you can outsource this to someone like okta.com if necessary), so that all internal systems never have a place to set a password. (e.g., don't make people set up separate accounts with passwords on the corporate jira or bitbucket server)
Basically, not training people to reuse passwords internally can help them to not reuse their one internal password externally.
Another possibility is to simply buy a password manager subscription for every employee and have it as a perk. That's a per-employee overhead of $20-30/year.
We can certainly do without passwords for every stupid little website. Unless you're rightfully a central force in the user's life - say, their main bank - you really should have users log in through Google, or Facebook, or Twitter, or someone else who almost certainly can guard their passwords better than you can.
It's shameful that it's so much easier to find tutorials on how to store passwords "securely" (including several tutorials that tell you crazy insecure things, like storing with unsalted commodity hashes) than it is to find tutorials on how to integrate your brand new battling-fairies website game with OAuth for authentication.
Don't store passwords at all if you can avoid it. Then, bend over backwards to avoid it.
Do all login through OAuth or the related proprietary "login with" mechanisms Facebook and Twitter have. Offer your users a choice of mechanism, in the signup flow, and don't require that they first set up a password that they then replace with login-with-(whatever).
If you can't imagine what this looks like, open an incognito browser and go through the signup-for-an-account flow at stackoverflow.com. That should be what you're aiming for.
And worse, when you actually need to talk about someone screwing up and encrypting passwords (see http://www.xkcd.com/1286/ ), this mis-education of your readers will have to be carefully undone first.
My experience with writing real production Haskell code is this: your first large Haskell project will be a failure, largely from missed deadlines and being unable to properly judge what is going to be easy and what hard. (Unless you deliberately aim low and spend much more time than is really justifiable on something you could have done in some language you know better in a few days)
Your second one will take longer than it would have in PHP or J2EE or whatever else you're used to building web stuff in. It will, like the first, also be ugly but unlike the first project will eventually work. It'll also fall over catastrophically early on, but will be salvageable. Once past its initial deployment/perf issues, it'll sit and hum away quietly in a corner with much less care and feeding than traditional web technologies. (Though you'll keep wanting to go back to it, because it's more fun to work in that than whatever else you're working on)
The third production Haskell project will come together much more quickly. Unfortunately, by this time you'll probably be bringing other people on and this will be their first big Haskell project. (See above about what happens to first big Haskell projects) So the parts delegated to other programmers will fail to work, and there will need to be lots of hand-holding and discussion of type design at first.
Selling management on this is indeed difficult. I'll admit that I'm still not clear on how we sold the first (failed) project to management or how I convinced my boss to let me use Haskell a second time. I mean, I was there, but I don't know how I did it.
