7

The recent epidemic situation has given me enough time to reconsider my password security seriously. I have devised a detailed plan for how to use elements such as a password manager, 2FA, U2F keys, etc. in conjunction with each other to create the optimal security architecture for my personal use (according to my rather limited knowledge of information security).

Now, the plan grew to such an extent that I decided to write it down as a document, so that I remember how certain parts of it work, why they are designed in a particular way, the weak points and so on. Is it safe to show this plan to, e.g. a friend who is also interested in strengthening their security? What about a hypothetical, extreme version - to share it online?

According to the Kerckhoff's principle, the security of a system should not depend on its secrecy. That's what I had in mind when designing my plan. I believe that anyone competent enough to try to break my system would also not be obstructed by the lack of knowledge of the design. Its strength relies on secret keys (and some informed use of MFA), also in agreement with the principle. However, I have seen on this site that sometimes users are scolded if they reveal a lot about how they organise their security in a question.

We can easily find how AES or public-key cryptography work in a few moments. That doesn't prevent them from being widely used and considered safe. Would the same reasoning apply to my personal scheme?

1
  • 1
    The lesser they know, the harder it will be for them to find your weak spot. This can work both for and against you. sharing your plans with people you trust can help you find your weak spots, and also will help you make sure you are completely covered just by the fact of thinking about this whole thing while explaining it to someone else. So for all I can say, it's fine to share your plans, but better not to do that publicly.
    – gkpln3
    May 13, 2020 at 18:17

3 Answers 3

3

There is always some risk involved because your method might have some flaws, and if an attacker can easily know all the details of your implementation then, of course, they have an advantage. To reduce the risk, some obscurity is sometimes used as an extra layer of protection in case something goes wrong, and as a deterrent. Here are a few points you can consider to evaluate the risk:

  • Who are you going to show your plan to? Friends? Coworkers? Security auditors? Haxxor forumz? The whole internet via social media?
  • What advantages do you get if you show somebody your plans? Are you going to get valuable opinions? Do you really need more opinions? What is your goal when you publish your method? Would you like it to become a widely recognized standard or common best practice?
  • How confident are you that your plan is already good enough? Are you aware of the current best practices? Have you tried to follow them?
  • How flexible is your system? Is it already in use? Is it still in the design stage and could be modified relatively easily? Or is it hard to change anything in the process?
  • Who are your enemies are what assets are you protecting? If the potential damage is severe and the probability of advanced attacks is high, then, of course, you will need to be more careful.

Answering those questions might help you figure out if it's worth sharing information with other people, and if you are increasing the risk or reducing it. So for example, if you are unsure about your practices, you'd better share your methods before you start to use them, to hear opinions from trusted experts (for example asking about your methods in this community). But if you are part of a team of security experts that works for the government, maybe you'd better shut up instead of publicly twitting about every detail of every security control your agency is using.

OPSEC best practices can be summarized as "shut up unless you really need to speak". In your case, it's probably OK to share your method with your friend, to help them improve their security. But posting that information publicly on Facebook would be bad OPSEC, no matter how secure your method really is.

0
1

Your reasoning is solid. A bit like a good encryption algorithm, knowing the process (inc the code) will not be sufficient to break it.

If the process is secure and you are able to maintain the keying aspects secure and under your control, I don't see sharing the process as being unsafe.

As a parallel argument, there's scope to have a recovery process from a 3rd party, in case of incapacitation or death (sadly a reality in the world). For this, a document like the one you referred to is critical, then you'd need to find a secure way to distribute keying material to trusted 3rd parties.

0

It SHOULD be safe. Otherwise, you already have a design flaw. Since you are already mention not to rely on "security by obscurity", I guess your plan is safe.

Your plan should also be quite simple, and I wonder why you need to write it down.

E.g. my "plan" is to never use the same password, use long ones, then use a password manager. On some sites I additonally use 2FA with the TOTP-Protocol. That's basically it, except for those sites that have other requirements....

1
  • 1
    This is also similar to my plan. The reason I wanted to write it down is that I also have some other details about which websites I have deemed (non-)critical, how I will store the backup recovery codes in case I can't use MFA anymore, all the worst-case scenarios, etc. The plan itself is quite simple, but I needed to explain to myself the logic behind designing some steps in a particular way.
    – dzejkob
    May 14, 2020 at 9:57

You must log in to answer this question.

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