Q:

Canonically, are there any security concerns with this system?

It was suggested that I ask Security.meta for opinions on creating a canonical question for those that can be summed up as "I created a complex system. Are there any security concerns with it?"
These questions tend to produce two types of responses (at least, this is how I respond):

Yes, because...
Probably, but I'm keeping my mouth shut.

Some of these types of questions can produce good answers, while others will generally be ignored, or produce unhelpful answers.
I'm proposing that we create the canonical question to cover the questions that are unlikely to produce useful answers, and the answers should give advice for those who find themselves seeing the dreaded "Possible duplicate of ..." comment.
I'll include an example question and answer as an answer to this meta post, as well as a "no, 'tis a silly thing, let's not do that" option as another answer to post on.  I also welcome suggestions as other answers (so I suggest that people hold off on voting for a couple days, until suggestions are in).

A:

Question title:
I created a complex system. Are there any security concerns with it?
Question Body:
This is a canonical question to help people who have created a process, application, procedure, algorithm, etc., to keep their systems secure and who are looking for feedback.
If someone marked your question as a possible duplicate of this question, then you're on the right track. You have thought long and hard about an issue, and have considered some of the security implications.  However, due to the unique nature of both StackExchange and of the Information Security SE site, you're unlikely to get an in-depth answer.
This does not mean that your question is done, unless your question has also been put on hold.
If someone has insight into the type of system that you're developing, and they know of a better way to accomplish what you're seeking, they may still leave answers (and are encouraged to do so).  It typically takes time for questions to be put on hold, unless they're obviously off topic, so breathe easy and read the answer(s) here.
This is different from most canonical questions throughout StackExchange, as there isn't really a single example of this question, and it doesn't neatly fit into any one tag. Rather, it covers a whole class of questions across a broad range of topics.
Answer 1:

I created a complex system. Are there any security concerns with it?

From the perspective of this site, there are two answers:

Yes.
Probably.

If we know that there is security issue, we'll tell you.  You'll either get a helpful comment or a full fledged answer soon.
For example, if you have UserIDs encoded in a cookie, and you want input on a way that you created to further obfuscate that UserID, we'll tell you to use a nonce instead of using the UserID.
If, however, we don't know of a better way to accomplish what you're seeking, then the answer changes from yes, it is insecure to it is probably insecure, but we don't know enough to provide insight.
Let's break that apart:
Your system is probably insecure.
This isn't meant to discourage you. It is only meant to warn you to be careful.
You have already taken the first step in creating a more secure system: you have identified a potential way for your system to be exploited, and you cared enough about it to take it seriously.
However, seasoned professionals in the field also create insecure systems.  These professionals may do it less frequently than the rest of us, but it happens, and often with dramatic results.  (See also: Heartbleed, Rowhammer...)
When you do your risk assessment, assume that the attacker knows everything that you do, and probably more.  If you can afford to lose all of your data (and if you have customers, then all of the trust of your customers), then keep playing; it will be a great learning experience.
Just never try to roll your own security in a real-world environment; trust the tried-and-true security best practices.
Remember Schneier's Law
Original:

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.

2006 version:

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Even if Bruce Schneier came here himself and asked "is this insecure?" my first answer would be "Probably," and I'm nowhere near qualified to evaluate any system that Schneier creates.  This is mainly because any serious system Schneier would post would be submitted to a journal first, and not here, but that's context specific.  Anyone coming here to ask if a system is secure will have a "probably" answer by default, until it is proven that yes, it is insecure.
We don't know enough to provide insight.
This is a good thing.
We're internet strangers.
Some of us are malicious.
We're all extremely curious, and like to pick apart interesting puzzles.  That includes obscure security practices, weirdly formatted data, and seeing if, since our userID is 41, whether or not we can see user 42's data without authenticating as that user.
You don't want us to know the minute details of your system, unless you have drawn up a pen-testing contract and have paid us.
If you do want many eyes on your system, it should be open source. If it's academically significant, you should submit it to a journal. (You don't have to be part of academia to submit papers to a journal, but it helps.)
You don't want us, in the course of answering questions for fake internet points, to poke at your system too hard.  For the most interesting questions, we might spend a few hours on the problem.  Most of us are interested in spending a few minutes, then going to the next source of fake internet points.
There is some small measure of fame for us, for coming up with great answers.  It's not going to pay our bills, though. It won't put food on our tables.  Either we find a hole in a few minutes of poking, or we don't...  Keep in mind that, in the case of security critical systems, many thousands of person-hours are spent on the topic, which changes our answer from "probably insecure" to "might not be insecure."  If you're lucky, we might spend dozens of person-hours on your system, across our whole community.
If we can't, within a few hours, say that "yes, this is definitely insecure, and a more secure way to do this is...", then we're the wrong people to answer your question.
Keep in mind, though, that you've already taken the first step in the right direction.  You are already concerned about the security of  your system.  Feel free to stop by chat; we'll generally point people in the right direction, or at least give you enough jargon so they can find the directions you need to go yourself.
If you'd like help in coming up with a way to reword your question, come visit us on Meta.
If you need enough of our sweet fake internet points to post in Meta, lurk around here for a bit and help people out. We may be gruff, and our comments may sometimes come across as criticism, but we're honestly happy to see more people take an interest in security.

