Encode Function
- Thread starter Chopper
- Start date
Larry Leeth
New Member
ENCODE is a proprietary algorithm.
If I told you then I'd have to ....
no - wait that's the wrong response.
Seriously though, I asked about this myself some time ago.
ENCODE is not based on a public algorithm like MD5 or SHA-1.
I submitted a request for a replacement (or additional) function
that is based on a strong, public one-way hash algorithm.
No word yet on if or when Progress will act on this.
ENCODE was probably fine when it was implemented, but it's time
for something stronger now.
-Larry
If I told you then I'd have to ....
no - wait that's the wrong response.
Seriously though, I asked about this myself some time ago.
ENCODE is not based on a public algorithm like MD5 or SHA-1.
I submitted a request for a replacement (or additional) function
that is based on a strong, public one-way hash algorithm.
No word yet on if or when Progress will act on this.
ENCODE was probably fine when it was implemented, but it's time
for something stronger now.
-Larry
Chopper said:
toby.Harman
Member
Why would you do this?
If you need to crack the code to achieve some task then develop the cracker. Releasing it to the world at large simply creates problems for all the people out there who have relied on this simple but effective proprietary solution.
I would also point out that this may be deemed as "deconstructing" the Progress source code and may land you in legal issues.
I agree that it would be an improvement to use one of the many industry standard encryption algorithms, and PSC should be implementing this.
If you need to crack the code to achieve some task then develop the cracker. Releasing it to the world at large simply creates problems for all the people out there who have relied on this simple but effective proprietary solution.
I would also point out that this may be deemed as "deconstructing" the Progress source code and may land you in legal issues.
I agree that it would be an improvement to use one of the many industry standard encryption algorithms, and PSC should be implementing this.
Cracker
I believe it's been mentioned before that security through obscurity is not really security at all. With some of the software that is being developed using the progress database it is very important to know what level of security they are providing. Such as with the Health Care industry, with the new HIPAA regulations it is actually required by law that a facility does a security analysis to make sure no medical records are at risk. Without knowing what level of encryption they are using in the encode function it is very hard to determine if it is really secure or not. Who is to say that ther are not thousands of text strings that may encode to exactly the same thing.
In order to be able to have a secure function something like a public cracker is necessary to make the Progress people realize that it is necessary to use a more secure algorithm.
I believe it's been mentioned before that security through obscurity is not really security at all. With some of the software that is being developed using the progress database it is very important to know what level of security they are providing. Such as with the Health Care industry, with the new HIPAA regulations it is actually required by law that a facility does a security analysis to make sure no medical records are at risk. Without knowing what level of encryption they are using in the encode function it is very hard to determine if it is really secure or not. Who is to say that ther are not thousands of text strings that may encode to exactly the same thing.
In order to be able to have a secure function something like a public cracker is necessary to make the Progress people realize that it is necessary to use a more secure algorithm.
toby.Harman said:
Mike Carroll
Member
>[snip]... is not really security at all.
This is true, by design. Progress doesn't have any built-in data security. Why? Probably because it isn't widely needed and there are many packages out there that can do the job better than the 4GL.
The ENCODE function was never meant to be used for critical data security. It's a simple password encrypter. A User registers a password which is encoded. When the User signs in, they retype the password which is encoded and compared to that stored. If the strings match then great! No need for a decoding facility at all. That's all it is designed to do and it does it very effectively.
>In order to be able to have a secure function something like a public cracker is necessary to make the Progress people realize that it is necessary to use a more secure algorithm.
Then why don't they use one? If security is a real issue for the application, then the authors need to go and buy some security software. This doesn't need to be provided by the 4GL.
This is true, by design. Progress doesn't have any built-in data security. Why? Probably because it isn't widely needed and there are many packages out there that can do the job better than the 4GL.
The ENCODE function was never meant to be used for critical data security. It's a simple password encrypter. A User registers a password which is encoded. When the User signs in, they retype the password which is encoded and compared to that stored. If the strings match then great! No need for a decoding facility at all. That's all it is designed to do and it does it very effectively.
>In order to be able to have a secure function something like a public cracker is necessary to make the Progress people realize that it is necessary to use a more secure algorithm.
Then why don't they use one? If security is a real issue for the application, then the authors need to go and buy some security software. This doesn't need to be provided by the 4GL.
toby.Harman
Member
My concern is the "spoiling" tactics. Not the lack of or need for a higher standard of encryption and security.
As Mike suggests - it is not difficult to implement a process which will utilise an external encoding function and store it in a RAW data field. This obviously means that searching this data is next to impossible!
I am sorry if anyone thought that I was advocating an absence of security. That wasn't my intention.
I would love to see Progress provide a level of data encryption, but I am not sure what it would achieve to 99% of the people using it.
As Mike suggests - it is not difficult to implement a process which will utilise an external encoding function and store it in a RAW data field. This obviously means that searching this data is next to impossible!
I am sorry if anyone thought that I was advocating an absence of security. That wasn't my intention.
I would love to see Progress provide a level of data encryption, but I am not sure what it would achieve to 99% of the people using it.
