Pratosh wrote: > Phew!! > Quite a few suggestions ... > > I wrote a program to Encrypt and then Decrypt ... but the same > security issue of "storing the key" is popping up now ...as pointed > out by a couple of people above. > > Well, to be clear, i will tell the scenario once more > > There is an interface A which uses a user B (T24 Super User) to > created LD records in real time during the day. > The credentials for B (User name and Pswd) are stored in a parameter > table from where the interface reads the values. > > We do not want anyone to see this stored password as the user is a > Super User and thus the pswd shld be encrypted at the time if storage. > > I created a validation routine and attached it to the template, so > that it encrypts the pswd each time it is entered. Then the decrypt > will happen inside the interface where the encrypted value will be > read and the pswd will be decrypted. The only problem now is the > storage of the key. > > As the code is accessible to IT users, they can easily see what is > happening inside the routine and get the pswd. So, the storage of the > key is an issue now. We are thinking of storing the key in a file > system inaccessible to the users but accessible to the program. But > that doesnt sound too secure either. > > Any suggestions?? I think you need to be very careful here as basically you are in danger of exposing T24 super user privileges to everyone.
Firstly, if you want to just get a bit ore secure to start with, do not under any circumstances store the actual password. Use a one way encryption and store what is encrypted, then encrypt what the user enters using the same routine and compare the result of that encryption with the encrypted string you stored. This will at least mean you are not storing the actual password anywhere as you cannot recover the password from a one way encrypt. Even if someone reads the encrypted password, they cannot get the original back from it. However, when they can read the encrypted key, your security is severely compromised because this kind of thing is subject to dictionary attacks - one way encryption routines may produce the same encryption for many different inputs and so a hacker need only find any password that does that. However, I think you need to rethink this. A better way would be to get your interface that produces records to run autonomously, accept requests from trusted sources, and produce output accessible by that trusted source. Ideally you would use message queues over secure sockets to do this. The connection must authorize, but not with the T24 super user password, and the receiving interface only performs a limited set of tasks (separate it from the code that runs those tasks). The receiver interface also authorizes with the connection, but again not with the T24 super user password just the connection password. The routine that creates the data runs somewhere else and never stores any keys or passwords as it must be started up by a user with the correct security privileges. Hopefully you get the idea. Jim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
