Recover Password from .ini file

[missile77]

Hi,
I have some .ini files and I have to recover a password from one of this.
I have to enter in a sun machine from root console and I don't remenber the password.
Do you known a method for decrypt password from configuration file?

thanks
missile

[bgagnon]

Hello missile77,

We do not offer a mechanism to "decrypt" stored passwords, as this would be a security risk. You should contact the administrator of the remote device to have your password reset.

[Olaf van der Spek]

Isn't that security through obscurity?

[jdev]

Originally Posted by Olaf van der Sp

Isn't that security through obscurity?

The SSH1/SSH2 password stored in a SecureCRT session configuration file is not merely obscured, it's encrypted. Security through obscurity would be more like saving the unencrypted form of the password in a hexadecimal format, or perhaps even under an option named anything but "Password" within the .ini file.

Regardless of how you want to define "security through obscurity", one of the main issues, Olaf, is liability.

The complexity associated with an individual needing to adequately prove they are the rightful owner of an .ini file containing a saved password makes it impossible for us to verify .ini file ownership. How do we know you are the rightful owner of the .ini file containing the encrypted, forgotten password vs. a hacker/thief who happened to illegally acquired someone else's .ini files?

Therefore, if we provided an easy way to recover an encrypted password, we'd be putting ourselves in a position of gravely undesired liability.

In most security-conscious situations, passwords can be changed easily, but it should be very difficult to recover a password. For example, if a user forgets their Windows/Unix login password, they petition their system administrator to change their password so they can gain access to the system. Note that the user doesn't contact Microsoft or their Unix vendor to recover their password; they contact their administrator who is authorized to temporarily restore the user's access to the system.

With respect to the issue of "security" regarding saved passwords, the "best practice" is to never save passwords in the first place. However, since a good number of customers demand the ability to save passwords, SecureCRT needs to put forth its best effort to ensure that it's very hard to get at the password simply by acquiring the .ini file.

--Jake

[Olaf van der Spek]

Originally Posted by jdev

The SSH1/SSH2 password stored in a SecureCRT session configuration file is not merely obscured, it's encrypted. Security through obscurity would be more like saving the unencrypted form of the password in a hexadecimal format, or perhaps even under an option named anything but "Password" within the .ini file.

The "through obscurity" bit comes from not telling where the decryption key is stored.

Regardless of how you want to define "security through obscurity", one of the main issues, Olaf, is liability.

The complexity associated with an individual needing to adequately prove they are the rightful owner of an .ini file containing a saved password makes it impossible for us to verify .ini file ownership. How do we know you are the rightful owner of the .ini file containing the encrypted, forgotten password vs. a hacker/thief who happened to illegally acquired someone else's .ini files?

You don't. But that doesn't seem relevant. It's like a virus/bot. If your PC is infected, it's no longer your PC. The same applies to sessions containing stored passwords.

Therefore, if we provided an easy way to recover an encrypted password, we'd be putting ourselves in a position of gravely undesired liability.

In most security-conscious situations, passwords can be changed easily, but it should be very difficult to recover a password. For example, if a user forgets their Windows/Unix login password, they petition their system administrator to change their password so they can gain access to the system. Note that the user doesn't contact Microsoft or their Unix vendor to recover their password; they contact their administrator who is authorized to temporarily restore the user's access to the system.

True, but that's because one-way hashing has been used. That's not the case here.

[jdev]

Olaf,

What problem are you trying to solve?

--Jake

[Olaf van der Spek]

Originally Posted by jdev

Olaf,

What problem are you trying to solve?

--Jake

Hi Jake,

Nothing, just having some discussion.

[rlarian]

all passwords are very complex and are stored in password vault, except one. We can copy/paste the encrypted line from the .ini to other .ini files and this works. however, for some unknown reason, some of the folks use putty - getting this to work in putty requires us to get the password (normally stored in the vault).


Please don't require that I do something like THIS

[miked]

This looks like the same question that was originally asked, and answered. We cannot provide a way to decrypt a password in a .ini file when there is no way to prove that you are the owner of the .ini file.

The complexity associated with an individual needing to adequately prove they are the rightful owner of an .ini file containing a saved password makes it impossible for us to verify .ini file ownership. How do we know you are the rightful owner of the .ini file containing the encrypted, forgotten password vs. a hacker/thief who happened to illegally acquired someone else's .ini files?

Therefore, if we provided an easy way to recover an encrypted password, we'd be putting ourselves in a position of gravely undesired liability.