I would suggest to the developer that it's a bad idea to write one's own password policy.

@Bill_Stewart does this mean that you're referring yo some kind of public standard instead? Cause if so I'm interested to know which one you are referring to.

No; but the rules on that page suggest a home-cooked solution rather than relying on an underlying authentication (such as AD). I could be wrong, of course.

From the twitter post it seems like this is a SAP product... I wouldn't call that home-cooked, but very bad nonetheless.

To me the only objectively poor choices in this policy are exactly 8 characters (which is pretty much the worst, IMHO) and having it not be case sensitive (and who does that?). Not containing spaces is not that unusual (e.g., Microsoft Office 365 cloud account passwords can't have spaces - yes federated ones can), I think restricting the starting character is probably lazy coding. And I guess making the first three characters different does reduce the entropy somewhat. The worst is that "p@ssw0rd" is valid and therefore would probably be popular.

Think of User Edward. He's extremely security minded, and wants to use a unique 20-character long password consisting of lower and upper case letters, numbers, and symbols. If your password policy prevents Edward from using his desired password, then your policy is worse than no policy at all.

@Darthfett I think the crux of the question is, "How many Edwards are there versus Jacobs?" Who is Jacob, you ask? Jacob hates even having to use a password and wants to use the simplest password possible. If he could Jacob would use a password of 1234 or 12345678. If a certain population of users is 99 Jacobs and 1 Edward, then I argue having no policy is worse. Of course if the population is 99 Edwards and 1 Jacob, then a bad policy is worse. Sadly, I think Edwards are hard to find while it's well document that most users are Jacobs.

In general it's trivial to construct a password policy that's worse than nothing: "all passwords must be 'password'"

As a developer I can see how this comes about. It doesn't make it right, but that list smacks of support and marketing having to much control over the development process. That's the stuff that comes from back and forth of trying to eliminate the "forgot password problem".

@OrangeDog There are still many places where that is the password policy.

You could always use the rms password policy - the empty string.

When I was in the infantry, in Iraq, the Army rolled out its newfangled system. The Army's password policy is and was as awful as the one in your image. I ended up sending an email to the help desk folks saying I discovered they stored passwords in plaintext on the client. A little while later I got an email back. It had been forwarded a few times. Some officer asked me what I was talking about. "Well, this password policy is so insane that everybody is going to write their password on a Post-It and stick it to their monitors". He wasn't happy. I thought it was funny, because it's true.

@coteyr It's not until you stop seeing the "forgot password" thing as a problem that you can even start being safe with your own passwords.

Exactly eight characters long sounds like lazy programming to me! Why eight characters?!! Thpough I would say a password policy is always better than none at all

@pipe is there a story behind the RMS policy?