Process isn't a substitute for thinking, process is a substitute for forgetting. A well designed process is simply the thing you'd do if you could keep every *actually* important detail in your head at all times.

You should certainly file bugs against a process (in the same way you would against any work product) if you perceive that a step or steps is useless or wrong.

You *are* following a process, it's just ad hoc, and maybe made up on the spot. Formalizing that process is a way to make it repeatable, and debuggable.

That said, and to reiterate, you must fight against the bad process. Bad process isn't clear. It's a bad program. Debug it.

So, thinking like a would be cracker, the list of basic places to try first:

Persons front door.
One of their windows.
A bank near their house.
Their car, if visible.

Etc. Given the usual kind of passwords people choose for themselves, I expect this will be similar.

Of course, this assumes the cracker can figure out the person's address, but we know how easy that can be.

I have been teaching people to use a complicated random password, but to go ahead and write it down. Then the basic security problem is getting them to control that piece of paper (keep it in your wallet, please), and makes over-the-net cracking much harder. Most of my users never had a problem with this.

People are dumb. Millions of people would select something like the entrance for Fort Knox, or Norad, or a local bank. You have a training problem just as large as the one you have now.

Except that the space is never not filled. 0 is a valid address. The certificate means we haven't figure out how many apples you have yet.

1. Do not belittle or otherwise blow off the customer's fear. In fact, hear it, and agree that it's something to think about.

Them: "I'm worried about this Linux stuff. A guy was telling me that anyone could see the code, and just know how to hack it!"

You: "I can understand how that could be a concern. It is a little like having a map of the valuables in your house taped to your front door."

2. Explain why openness is helpful

Them: "Yeah, so what should we do?"

You: "To be honest, sir, the reason why we like that anyone can see the code is because that means anyone can fix those problems. And lots of people do, for the very same reason you are worried about it. They need something that's secure, and isn't going to surprise them."

3. Mention that serious people have a big stake in making this work.

You: "I should mention that a few companies have bet a lot of money on open source, and wouldn't be happy to see it easily broken. IBM, Novell, and Oracle, to name a few, have very large investments in Linux, and have donated many patches to make sure the code is secure. And for that matter, so has the NSA. They have actually extended the security quite a bit, with their Security Enhanced Linux."

4. Reassure them that people are thinking hard about this.

Them: "Yeah, but if anyone can see it..."

You: "...then you have to be extra careful. See, the strategy that Open Source follows, and everyone should, is to assume that everyone *can* see the code, so you better design it so that the real keys to the kingdom aren't in the code at all. You make sure the keys are completely in the hands of the owners of the system, so it doesn't matter if you can see how the lock works, you still don't have the keys."

5. Point out the obvious.

Them: "But what happens if someone tries to slip something in, and is really good at it?"

You: "Once in a while, someone tries. But when a thousand people might look at the files you are trying to sneak in, someone's going to notice. And then a hundred thousand geeks will make fun of you. In public, all over the internet."