Rcon Utility

[Undeference]

• Mention of security through obscurity was before you disclosed your "security" measures
• Your program's purported security may give some users a false sense of security
• Just cut out the cryptographic code, which adds nothing to your program anyway, and recompile and redistribute it with the full source code and [most] people will stop complaining

Or don't

[Teapot]

Ohhh, you aren't talking about a proprietary algorithm. You mean the secret key?
If you're talking about using a secret key you put in the binary, I believe it can be retrieved.

[F50]

Ohhh, you aren't talking about a proprietary algorithm. You mean the secret key?
If you're talking about using a secret key you put in the binary, I believe it can be retrieved.

This is why its security through obscurity. Given an untrusted client, who, as you've said yourself, is free to decompile the binary, the "password" can be discovered by mere inspection.

I still don't understand though:

As for this "Rcon Utility", I have no idea where/why encryption would be used anyway, since rcon does not use encryption.

So wtf does the encryption exist in the first place?

[kharnov]

I never dreamed of the day I'd see someone troll a forum with software.

[Tremulant]

So wtf does the encryption exist in the first place?

He's encrypting the saved keys on disk, we've covered this.

[Foe of Eternity]

I never dreamed of the day I'd see someone troll a forum with software.

well it didn't start like that but it turned into that (sorta)

continuing on...there's no password hidden in the binary, you can look yourself
and thank you tremulant, you see why i get frustrated >.>

[Teapot]

Where does the program get the secret key from?

(keeping in mind that if it is stored as a variable, it is stored as plain text in the binary)

[Foe of Eternity]

it doesn't store it as a variable either
but why would i tell you how i generate the password...kinda defeats the purpose of the password don't you think?
so yes, it is proprietary

[Teapot]

The method can still be discovered by decompiling.
And your security relies on hiding the details of the secret key generation -- security through obscurity at work.

[Foe of Eternity]

no, security through obscurity would be hiding everything about saving the password, hiding the password generator makes it a proprietary algorithm
security through obscurity implies that there's holes in the security that the owner won't acknowledge as a hole and hides it so they feel safe because they think people won't figure it out
proprietary algorithms are algorithms used to generate a result that have been hidden to prevent misuse

[Teapot]

security through obscurity implies that there's holes in the security that the owner won't acknowledge as a hole and hides it so they feel safe because they think people won't figure it out

Explain to me how this definition does not apply here.
You won't acknowledge there's a hole in your software, you're hiding the details because it makes you feel safe and you think people won't figure it out. Perfect match.

I (and others) maintain, this is still security through obscurity.

Security through (or by) obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security.

[Foe of Eternity]

the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source

[Tremulant]

the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source

Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.

[Foe of Eternity]

the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source

Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.

i don't think you understand what security through obscurity is, security through obscurity is not releasing the source to prevent security holes


i'm not releasing the source so people can't [Edit]recreate the password without difficulty[/Edit], which as i said earlier, is a proprietary algorithm
they're completely different things; i'm not using security through obscurity

[Teapot]

Your program's design has this flaw regardless of whether or not it is open source.
And you are failing to understand what security through obscurity is, not everyone else.

[Foe of Eternity]

and what might that flaw be?
that it has a generated password?
what about other programs with generated passwords?
are they all using security through obscurity too?

what you fail to see is the reasoning behind why i'm hiding it, there's no need for me to repeat myself like i did earlier

[Tremulant]

i'm not releasing the source so people can't crack the password

i'm not using security through obscurity

[F50]

the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source

Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.

i don't think you understand what security through obscurity is, security through obscurity is not releasing the source to prevent security holes
i'm not releasing the source so people can't crack the password, which as i said earlier, is a proprietary algorithm
they're completely different things; i'm not using security through obscurity

It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.

If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information, such as the exact time the user generated the password, then the password itself could be considered secure (well, to a point, passwords really should be generated by an absolutely safe algorithm, or not generated at all), while the password generation algorithm itself is merely is security by obscurity.

[Foe of Eternity]

as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.

Your argument is invalidated because you failed to not only read, but understand.

I will explain the purpose of the encryption again so you understand why it is there

The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text

The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people.  You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure.  Not only is this false, but impractical.  The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted.  I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password.

As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity

[Teapot]

Your "given requirements" are that the data be encrypted and decrypted without user interaction which has a security vulnerability inherent in the design because such requirements rely on data which is all available on the machine (even in an obscured form), unlike passwords.

[Tremulant]

Your argument is invalidated because you failed to not only read, but understand.

I will explain the purpose of the encryption again so you understand why it is there

Look, f50 is clearly a bit slow, just ignore him, it doesn't stop your system incorporating security through obscurity, your reversible password encryption method is secret, if it weren't secret(and you can't assume it'll stay secret) it'd be really easy to reverse the encryption on saved passwords.

[Foe of Eternity]

it's not secret at all, i already told u i was using a rijndael cypher

and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it

all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is

as i said before, the only security is trust

[Teapot]

the encryption only prevents other people from accidentally finding it and realizing what it is

Lol. You might as well do rot13 on the rcon password given that the above is the only reason you're using encryption. And for either method, the only protection is against people noticing a password like "ThisIsRconForMyServer".

[Foe of Eternity]

if u knew me you'd know i overdo stuff ^^

i incorporate overcomplicated stuff in simple stuff for practice

[F50]

as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.

The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text

I do understand that the encryption is not being used between the program and the tremulous server, but it is still possible to use other secure and random approaches, as is done with ssh keys. Many ssh keys are stored are encrypted on the machine, in a similar, but actually secure, way. However,

If the plain text file on your computer is not considered secure enough, then the natural assumption is to evaluate the problem as if Eve has access to the file, is it not? It is also given that everyone (and thus Eve), has access to your binary.

Now, let me duplicate my previous post for you:

It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.

If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information,

I'll stop there, because it doesn't. Its security by obscurity because everything necessary to decrypt the rcon password has already been published in the forum of the binary.

To continue

The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people.  You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure.  Not only is this false, but impractical.  The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted.  I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity

Yes, I can, because you already have revealed the method of password generation in your binary, and that knowledge is *all* that is necessary to recreate the rcon. You need to use information that is truly secret (and not just published in assembler, tremulant) to encrypt and decrypt your information here. SSH has done this.

I would stress that all of the methods, as well as the source code for ssh is public. Only the passwords are private. Your algorithm is insecure because the source code for your own cypher is readily available to any hacker that cares to go through the assembly, whereas ssh is not insecure, because the source code (available in hard-to-read assembly as well as some implementations in C) does not need to be secret, only the passwords (at least one of which must not be available on any computer to be secure).

[Tremulant]

(and not just published in assembler, tremulant)

Hello?

[Foe of Eternity]

as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.

The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text

I do understand that the encryption is not being used between the program and the tremulous server, but it is still possible to use other secure and random approaches, as is done with ssh keys. Many ssh keys are stored are encrypted on the machine, in a similar, but actually secure, way. However,

If the plain text file on your computer is not considered secure enough, then the natural assumption is to evaluate the problem as if Eve has access to the file, is it not? It is also given that everyone (and thus Eve), has access to your binary.

Now, let me duplicate my previous post for you:

It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.

If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information,

I'll stop there, because it doesn't. Its security by obscurity because everything necessary to decrypt the rcon password has already been published in the forum of the binary.

To continue

The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people.  You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure.  Not only is this false, but impractical.  The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted.  I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity

Yes, I can, because you already have revealed the method of password generation in your binary, and that knowledge is *all* that is necessary to recreate the rcon. You need to use information that is truly secret (and not just published in assembler, tremulant) to encrypt and decrypt your information here. SSH has done this.

I would stress that all of the methods, as well as the source code for ssh is public. Only the passwords are private. Your algorithm is insecure because the source code for your own cypher is readily available to any hacker that cares to go through the assembly, whereas ssh is not insecure, because the source code (available in hard-to-read assembly as well as some implementations in C) does not need to be secret, only the passwords (at least one of which must not be available on any computer to be secure).

Look, f50 is clearly a bit slow, just ignore him, it doesn't stop your system incorporating security through obscurity, your reversible password encryption method is secret, if it weren't secret(and you can't assume it'll stay secret) it'd be really easy to reverse the encryption on saved passwords.

let me quote my other post:

it's not secret at all, i already told u i was using a rijndael cypher

and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it

all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is

as i said before, the only security is trust

SSH is secure because the password is stored on the server
not only is your argument completely invalidated once again, but once again, you failed to understand how the program works

Here's what i said, ONCE AGAIN:

it's not secret at all, i already told u i was using a rijndael cypher

and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it

all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is

as i said before, the only security is trust

SSH, by the way you're looking at my program, is even less secure than my program.
With ssh, you can recreate the session by capturing the keys and spoofing data as it's sent to the client, and not only that, but you can bruteforce ssh keys, all without permission from the owner.

My program doesn't use the internet at all for it's programs, so the only way anyone can get the password (with any method) is by getting it from the owner's computer

Please read before you post again.

[gimhael]

ssh keys are asymmetric keys, i.e. they consist of the public and the private subkeys. The subkey on the server is the public subkey, which may be published openly without compromising the security of ssh at all. The private key (which you can consider the "password") is in fact stored on the client side.

Also you cannot get the secret keys by snooping the communication. The keys are never sent over the wire, so capturing them is simply not possible. Of course you can break the encryption by brute force, just like you can break Rijndael or every other cipher in existence, if you have the necessary resources...

as i said before, the only security is trust

Yes, but it is obviously easier to trust a program which I can check and compile myself with a trusted compiler than a random binary blob downloaded from the internet.

In the end this whole discussion leads nowhere. If you don't want to show the source code, that is your descision. And if someone else does or does not trust your program, it is his descision.

[F50]

your reversible password encryption method is secret, if it weren't secret it'd be really easy to reverse the encryption on saved passwords.

The main problem being, its in the assembler, the method is not secret.

Please read before you post again.

Believe me, I've read that, but I believed you were more competent than your post seems to suggest. Are you asking me to apologize for having misunderstood? I assume of course that the post you've repeated twice is what you intended for me to read. It seems like you're saying that your encryption method is as good as plain-text, which shares all of the qualities given in that post. Having read the wikipedia article on the AES algorithm I am even more confused, as that seems clearly better than plain-text, provided that the key is not stored anywhere on that machine.

So then, your security is not meant to be security? I'm interested then in why its so important that this remain secret...

AFAIK, AES is not proprietary.

[Foe of Eternity]

ssh keys are asymmetric keys, i.e. they consist of the public and the private subkeys. The subkey on the server is the public subkey, which may be published openly without compromising the security of ssh at all. The private key (which you can consider the "password") is in fact stored on the client side.

Also you cannot get the secret keys by snooping the communication. The keys are never sent over the wire, so capturing them is simply not possible. Of course you can break the encryption by brute force, just like you can break Rijndael or every other cipher in existence, if you have the necessary resources...

as i said before, the only security is trust

Yes, but it is obviously easier to trust a program which I can check and compile myself with a trusted compiler than a random binary blob downloaded from the internet.

In the end this whole discussion leads nowhere. If you don't want to show the source code, that is your descision. And if someone else does or does not trust your program, it is his descision.

I was using the way he was comparing ssh to my code to show that his argument was invalid, i never said ssh was insecure, in fact it's very secure.  Also note the spoofing part, it is possible to hack ssh over the packets sent/received, as i said recreate the session using captured keys (public) and a little bit of spoofing (private)

as for the password, i meant that the password can be accessed from the client remotely (not like receiving it, but more like bruteforce)

on the note of source...
do we have to discuss this over again?
you'll find the source is already posted

your reversible password encryption method is secret, if it weren't secret it'd be really easy to reverse the encryption on saved passwords.

The main problem being, its in the assembler, the method is not secret.

Please read before you post again.

Believe me, I've read that, but I believed you were more competent than your post seems to suggest. Are you asking me to apologize for having misunderstood? I assume of course that the post you've repeated twice is what you intended for me to read. It seems like you're saying that your encryption method is as good as plain-text, which shares all of the qualities given in that post. Having read the wikipedia article on the AES algorithm I am even more confused, as that seems clearly better than plain-text, provided that the key is not stored anywhere on that machine.

So then, your security is not meant to be security? I'm interested then in why its so important that this remain secret...

AFAIK, AES is not proprietary.

when did i ask for an apology?
i'm saying you weren't competent enough to read

once again with the not reading: i never said the rijndael cypher was the security, and the cypher is only for me (and to add a little privacy)
i even quoted what i said the security was and you STILL can't figure it out?

and on the note of AES not being proprietary, when did i say it was? i said the algorithm i use to generate the password is proprietary
SERIOUSLY LERN2READ