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

  • 1
    While I like the answer you wrote, I am not sure if this is a good canonical question. We might risk closing questions that shouldn't be closed. Sometimes there is an obvious "Yes, because..." and then that is a good answer. If all the people who fit the second bullet point vote to close, the person with the good answer might never get to write it.
    – Anders
    Nov 28, 2019 at 9:23
  • Also, determine what counts as complex enough to warran a close vote (or duplicate vote I guess) is not easy. Something might seem complex for those not familiar with the topic, but for the expert ther might be a obvious and common misconception at the heart of the question that should be adressed in an specific answer.
    – Anders
    Nov 28, 2019 at 9:29

2 Answers 2


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


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.

  • Quick side question... Does anyone know the correct/preferred honorific for Bruce Schneier? Prof.? Dr.? I've thoroughly checked his About page, but only (quickly) skimmed the Wikipedia entry.
    – Ghedipunk
    Nov 26, 2019 at 0:15
  • 2
    If he doesn't include it on his personal site, then etiquette suggests that you are ok not to use it. I cannot recall ever seeing his honorific.
    – schroeder Mod
    Nov 27, 2019 at 8:50

No. We do not need a canonical answer of this type, or something more nuanced that could also warrant another answer or extended discussions in comments.

Now go away or I shall taunt you again a second time.

You must log in to answer this question.

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