Your notes are either incorrect or invalid on a few counts... > From: Jim Idle > Tony G wrote: > > Rather than using ENCRYPT(), or social engineering to > > discourage people from using passwords at all, it's > > very easy to do this with a .NET program called from > > BASIC: > > > > CLASS = "NebulaRnD.Security.TripleDES" > > INFO = "I am a password" > > KEY = "34M5945hjW4hvde87tsDcgkuy" > > > And there is the classic problem I referred to > earlier. You have secured it with tripledes alright, > but all I need do is run the strings command on your > program and you just gave me the key.
Personally, when working with secure code I always assemble and calculate key data at run-time, specifically so that open strings can't be read as you describe. Yes, it's a problem with implementation but not with the solution in general. All implementations of any solution can have problems no matter how stable the foundation is. That's where experience usually helps to add value. > I could also write a very simple program to whip > through system memory and find the key when it is in > memory (might need fairly high privileges, but the > program is probably running as the same user group as > me...). Yeah, and a truck driving through the wall of your computer room could compromise security too. C'mon Jim, are you just being contrarian? A system that has a vulnerability that allows rogue software to scan through memory has a lot more issues than securing individual data values. Suffice to say, nothing is safe in an environment compromised as you describe. Again, this is an implementation issue, not a fault with the solution. > I can also replace your .Net assembly with one of my > own that calls yours and emails me the keys as > CALLdotNET (I want to shoot the person that made the > 'dot' lower case), does not have a way to verify the > assembly is the one you think you are calling. Heck man, if you want to go down that route then why not replace executables in /bin and /lib too? Well, we agree with that lower case thing anyway. However, assemblies can be signed by authors with strong keys (which I do whether I need it or not) and keys can be registered on a system through Code Access Security which should stop unauthorized assemblies from executing at all. This is complicated by another implementation issue where CALLdotNET expects assemblies to be in a specific directory rather than in the Global Access Cache (GAC). Anyway... if someone has such a lack of security in their environment where assemblies can be substituted at the whim of some bad guy then there is no such thing at all as trustworthy code and implementation of encryption falls to the bottom of the list of things to do to ensure security. > This stuff is way way more intricate to get correct > than most people give credence to. Calling external > programs in almost any way means you might as well not > bother encrypting it, unless you just want to hide it > from random prying eyes. > > Jim Great, you've told us: 1) ENCRYPT is worthless. 2) Using outside methods is inherently insecure. 3) You can write code to scan memory for secure data and replace object code. As well as putting people in awe of your skills, all of this might leave people believing the platform is inherently insecure. In particular, I'm sure a lot of Temenos sites have a new appreciation for their software. Can someone else perhaps provide the OP with a solution that is suitable, stable, and supported? Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development and training services --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
