Security through obscurity and secrecy?

Are you using VanDyke's SecureCRT? Let's suppose you have forgot a password of one of your configured sessions: you can still log-in, since SecureCRT has stored it, but if you need to use that password from elsewhere and you can't remember it, what can you do?

SecureCRT can actually log in, and in order to do so it needs the password as plain text. Thus let's see where SecureCRT stores the password: soon you find the “session .ini files” and take a look at them.

The session .ini files are nothing but plain text files. Inside them, your password is stored in a line beginning with S:"Password"=u. In a glance you notice it is obfuscated someway.

Obfuscated? Why? Shouldn't it be crypted? No, I label it obfuscation, because SecureCRT needs the password as plain text; therefore it must be able to decode the encoded string, and since it succeed without asking you another password (e.g. a master password), then it does not matter if the used crypto-algorithm is the best crypto-algorithm¹ or not: it is just a function, and we know for sure that its inverse, altogether with all required additional data (e.g. a private key) is engraved in the software itself².

The SecureCRT's executable and data are a security hole and expose the “key” to “decrypt” the password. So it's still obfuscation to me³.

This means that the password is hidden from the eyes of curious, average, passive users. This does not mean the password is protected against persons determined to know it for their own (evil) purposes, once they put their hands on those precious session files…

These determined and aware persons usually do not post in the official forum of the producer of the software, asking how to obtain the clean password from the .ini files. Honest, average users of SecureCRT more likely do⁴. However, giving good advices won't disclose anything new and unknown, so it would be just a good customer strategy. (But this is another kind of matter.)

I have forgot the password, can I retrieve it from SecureCRT?

Clearly you can't ask for help to the VanDyke's technical support: their negative answer is granted; nonetheless I find surprising few statements made in this forum thread, where two users asked how to recover passwords⁵.

Since technical support must know that the password can be “decrypted” and that the “key to the riddle” is in the software itself, bothering and blabbering about the ownership of the .ini file is odd to me, and in the same time suggesting to «contact the administrator of the remote device to have your password reset» sounds like a standard unuseful answer—almost mocking.

The only acceptable answer would have been something like this: sorry but our liability policy prohibits to help you, or even give you smart and effective suggestions to solve your problem; but you can find other solutions by yourself.

Read differently, it means there's a way to recover the password (of course, it must exist, as explained above), but shhh, we can't suggest it, nor give working tools, of course! So, user Olaf van der Spek is right twice: it's «security through obscurity»⁶.

Thread closed, but not before the second asking user posted also a link to a working solution.

Don't ask, but search for answers to your question…

Very likely your problem is also someone else's problem, especially if it is a common problem: forgetting a password is a very common one (we should make efforts to relieve it, and our minds would also thank us). This is why there are many chances to find an answer to your question even without asking it.

It's plenty of interesting sources out there. Seekers are aware of the power you have once you learn how to search for what you want—you need only a little bit of experience in judging an answer⁷, discarding absurd and fragile solutions, and so on. Likely it mostly depends on your familiarity with the subject.

Anyway…

In this case you don't need special superpowers of any kind… the solution appears in a social network (Twitter), in a tweet containing all the obvious and main keywords: VanDyke, SecureCRT, session file, decrypt(ion)…

You have to know how to run the Python script, i.e. you need Python installed on your machine, and Crypto package installed too. It may be all very easy even for the common MS Windows users⁸.

System already violated

If a person has got a SecureCRT's session file, it means s/he had access to the system, at least for the time needed to copy it. If this person is a bad one, it means that the system was already violated and the remote systems configured in the session files are not safe anymore. In fact, having the SecureCRT session file, the bad attacker only need to install SecureCRT in order to connect to the remote systems, and to steal data from them or whatever, without the need to know the password.

Of course s/he is “limited” by the possibilities of a ssh connection… enough to believe that the worry on ownership of the session .ini files is a marginal concern that distracts from the actual security risk.

Remote systems configured in the session files must be considered in danger, if the users asking those questions are not honest as I, naively, am inclined to think.

---

1. It can't be an hash, otherwise it would impossible to recover the original password.↩

2. This is the main point: the fact that it's “easy” (if you really want…) to find the inverse function. You don't need to “crack” computationally uncrackable code…↩

3. Let us suppose the software uses public-key cryptography. The software crypts the password with the public key of the recipient (that is, itself…). Then, when it needs the password, the software decrypts the encrypted password using its private key. Public-key cryptography is crytography, but if used this way, it becomes just obfuscation: the public-private keys pair is “bundled” altogether with the software installed on my machine, and recipient and sender coincide. Then decrypting means, in essence, to find the private key, and the security relies all on avoiding to say where that private key can be found. Security by secrecy makes it “obfuscation”, not “true” cryptography (even if “true” cryptographic algorithm are involved).↩

4. Perhaps also kids who want to prove to be “cool hackers” to their mates but aren't able even to find a suitable place where to ask—and indeed this proves they are the opposite of a cool hacker, whatever it means.↩

5. User missile77 asked in 2009, and rlarian in 2011; rlarian also provided an actual solution that shows the paranoia about ownership of the .ini makes no sense: it's not a security-driven stance, and every “digital bad guy” out there had already the same idea—it's one of the easiest—plus several others.↩

6. «The "through obscurity" bit comes from not telling where the decryption key is stored». He also stresses that we are not dealing with a one-way hashing; therefore the comparison with the Windows/Unix login password reset scenario is misleading. In fact, in those cases you can't recover the clean password from the hash (what can be done easily is to try several strings, hash them and compare the result to the stolen hash). This “security” level is not reached by keeping the special algorithm and/or private key secret: the used algorithms are well known and there's no a private key in the game (as it happens in the public-key cryptography).↩

7. Crappy and bad solutions might seem convincing and good to unexperienced users.↩

8. On GNU/Linux is easier. If you have a .deb distro, synaptic, and APTs allow you to install Python and the requested package(s) swiftly. The same for distros using RPM. Installing Python on MS Windows is painless; installing the required package(s) could be a little bit trickier, but do not desperate: a click solution is not impossible.↩