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...
"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.
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.
