6 character minimum with at least 1 numeral and 1 lowercase letter. 6 character? No uppercase requirement(was list truncated)? As others have noted, "last character is a numeral" is a very common pattern, especially when a numeral requirement is imposed or passwords must be changed regularly, but prohibition for that reason is awfully sophisticated given the password length (only 6) and that no uppercase letters are required.

Typo? 56 -->50 50,135,658,326 = 26^8 - 26*25^7 -- still "about a quarter" (26.9 --> 24.0%). Note as well, with 52 character set, 12.7%; 62 char set, 10.8%. (I've simplified by not adjusting for passwords less than the max length.) Increasing the password length has the opposite effect, increasing the % removed.

As long as the longer (8-->9)result is not "passwords" or "password1". ;)

IF selected passwords were uniformly distributed (random) OR crackers only used brute force techniques, THEN I would almost agree that "Preventing consecutive characters reduces security." With few exceptions, passwords are not random and crackers are not stupid. Crackers use dictionaries and look for patterns like repeating characters (e.g., padding with Xs or periods or numeric sequences or keyboard patterns) along with selective brute forcing. Also, the example you have chosen is extreme (although I'm sure it happens): 2 consecutive letters.

Guidelines/regulations often lag current problems and (legacy) systems then perpetuate them. We also know a lot more now about how people create them and (inventively) attack them. Also see security.stackexchange.com/questions/10776/…

A few cringeworthy examples (many, but not all, dated): troyhunt.com/whos-who-of-bad-password-practices (do read comments) davidpashley.com/2014/04/16/bad-password-policies (from 2014 Heartbleed) kottke.org/12/06/the-worlds-worst-password-requirements-list badpasswordpolicies.tumblr.com

Many vendors provide use cases, whitepapers, and feature lists. Most (All?) business pwd managers provide some form of user (person/employee) account, shared (project, client, limited subscription, site) account, roles (pwd admin, project admin), privs (read-only, checkout), and emergency ("break box/glass", death) access to at least shared accounts (e.g., 2 of 4 preselected people agree, possibly after waiting period &/or email/text notification). Some products allow pwd admin access to every stored pwd except usermasterpwd; others have segregated "personal/home" vaults.

@Tobiq Just trying to clarify what/where you are measuring that takes 5-10 sec. Execution in intended environment matters. My question was incomplete. O'Neil and others have provided you with guidelines (that will conflict on low-end/overcapacity hardware) but you have to balance value of data (e.g., $, politics, brag), user patience, target hardware capability, and organizational constraints (e.g., regulation? liability? reputation risk?). Also see security.stackexchange.com/questions/42238/…

Are you running both sides on your (single) computer during development?

Slowing is the point. Number depends on risk, resources (server and app device) and application: Free game? Password manager? Store with 1-click purchase? Slow one time sign-up is much more acceptable than slow sign-in, but both are preferable to a breach. How secure is your password (user, salt, hash) file? Really?

In general for a block cipher, the larger the block, the more data (length & number of messages) you can encrypt without duplicating a block or leaking other key related info. By analogy, consider the Birthday Attack (see Wikipedia) concept of mm/dd match of class of 30 students. A match is all but certain if you only use dd (30 students, 31 days and '31' itself is only 7/12 as common, etc.) and certain with mm (if extreme of 1-12 all different, 13th child must match). Now consider matching 30 people on mm/dd/yy(birthdate) on mall escalator on 1st Sat in Dec (hence somewhat diverse ages).