There's been a ton of people asking about pattern based passwords for specific sites recently. Should we keep closing these and linking to the many, many duplicates, or should we make an anti pattern or canonical SE question so that these questions start appearing less?

Actually maybe this might answer another question of what the heck a canonical question is...

  • 2
    I think getting your question closed as a duplicate of another question that is sort of like yours, but not really is a frustrating user experience. You will get a lot of people saying "but this is not like my truly genious scheme". So I would say a more general canoncial question is a better dupe target than some random question about another scheme. If a dupe target is needed at all?
    – Anders
    Jun 6, 2016 at 20:32
  • Related: meta.security.stackexchange.com/questions/2180/…
    – user13695
    Jun 7, 2016 at 14:21
  • Could you provide some examples of questions like this? It seems that both answers are more focused on crypto algorithms, but I read yours to be more about simple rules for creating an easy to remember strong password?
    – Anders
    Jun 13, 2016 at 8:33
  • Creating a secure password scheme is basically crypto. Take random seed, do this and that, and then boop secure password(s). Oh no same problems as the rest of them! Coming up with your own crypto scheme should also probably be another anti pattern or canonical Q?. Jun 17, 2016 at 19:59

2 Answers 2


"Is this scheme secure" is an anti-pattern in general, not only on this site, but over the whole history of cryptography. The whole concept of an inventor spurting out his concoction and asking other people to point out the issues never worked well. Or never worked at all, in fact.

Long ago (before the Disco era!), cryptographers came to the conclusion that the only sane way to design a secure algorithm is to publish it with a thorough analysis that explains why it is secure, in a positive way (e.g. demonstrating that the highest probability differential is lower than 2-7 per round, not simply stating that they don't see how to break it); and then, a necessary second step is to submit the algorithm to public review.

One way to see it is to consider the direction of the convincing. In a properly conducted design process, the inventor tries to convince reviewers that his algorithm is secure. In a "is my scheme secure" system, the reviewers try to convince the inventor that his algorithm is not secure. The latter only leads to sorrow.

I don't think there is any technical way to deal with such questions that would not involve crushing the ego of the misguided individual who dares ask such a question. However, my preference would be toward a dedicated FAQ entry, and closing offenders as "not constructive" with a pointer to that entry.

  • All those questions so be pointed to this answer (in the comments)
    – user13695
    Jun 7, 2016 at 14:19
  • ... How do we make this the faq entry? Jun 8, 2016 at 22:48

How about something like:

Your question has been marked as a duplicate of this one because you've asked whether a specific security scheme you have developed is secure. This question is commonly asked, but it isn't really answerable on Security.se.

There are two stages to demonstrating that any conceived security scheme is secure. Firstly, the creator should themselves look to prove the strength, by demonstrating properties which can be mathematically proven which the scheme takes advantage of. Secondly, once they've done this, they should take these proofs and the scheme to other people, asking them to find any flaws. This is to ensure that the creator hasn't missed something in the creation or proof phases, and should be considered a positive thing - if flaws are found, they can be fixed, or the scheme can be halted before being used in live environments.

For example, the Keccak hashing algorithm, which became SHA-3, was first published in 2006, with the authors providing details on elements of previous hashing algorithms which they attempted to improve in a paper. They also proved mathematically various components of the algorithm, showing that various properties were held by it. It was then part of the NIST SHA-3 competition, starting in 2008, where some flaws were found by the teams of cryptographers looking at it, and it could be refined and improved to fix these. In 2012, six years after the initial publishing, the algorithm was selected as SHA-3, and the final version was published in 2014.

If you have created a new scheme, you should first look to find vulnerabilities yourself, building a working implementation and trying to spot undesirable features or flaws. For example, a new password storage method would need to demonstrate that it doesn't store the same value for two users with the same password, among other things, and this can be demonstrated easily. Only once you can prove that your system fixes known flaws in existing systems, or at least reduces them, should you look for third party validation. This could come from university researchers or specialist security audit companies, but takes time and resources which unpaid security.se visitors are unlikely to be able to offer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .