Forums

by Craig Shearer >> Sun, 16 Apr 2000 23:38:19 GMT

Hello all

We're developing an application at present to be deployed on the Smart Thin Client over the net, so we're naturally concerned about security. I've tried following the guidelines on the documentation about security - and it talks about the importance of encrypting the username and password, then decrypting it at the server end, etc.

I must admit that I find some of the documentation quite confusing. However, I've tried to follow the guidelines and it's working ok - we encrypt passwords when prompted for on the logon form, which should mean they are encrypted for transmission over the wire. Then, we decrypt them at the server end to compare them in the database.

I realise that in a thin client environment, we are also going to have to encrypt the comms otherwise it's this client/server encryption is pretty pointless (since the data will be transmitted unencrypted over the net from the thin client to the app server).

The main problem we're having is that this encryption is great, but JADE sets the process.userCode to the encrypted version of the user name, which means that if you look at the processes in the JADE monitor - you get garbage user names (in fact, we mistakenly thought that JADE was somehow corrupting them!)

Does anybody have any guidelines on how to do this properly?

--
Craig Shearer
Email craig.shearer@bigfoot.com

by Torrie Moore >> Mon, 17 Apr 2000 0:35:04 GMT

Just some ideas that we are using.

It is more important to encrypt the link. Every control property etc appears to be transmitted in unencrypted form unless the encryption has been enabled for the thin client. (Perhaps someone from Jade could confirm this?) Even if you write code to encrypt the password, the password will be passed back to the appServer unencrypted as the code only executes at the AppServer end of the link. This it is more important to encrypt the link than it is the password. If you encrypt the passwords at the appserver then they will be transmitted to the server as encrypted strings.

I think that you still should encrypt the passwords as soon as possible and would recomend that you use a one-way encryption for the password (as does NT and Unix). You encrypt the password and store it as an encrypted string. When comparing the passwords you compare the encrypted passwords. (There may be problems when connection through SQL etc where the plain text password is passed into the isUserValid method.) This is a better method as no-one can get into the object inspector or data files and look at the user objects to see the passwords. Even if they can see the password it is no use as it cannot be unencrypted to a usable form.

As for the encrypting the username, is it really necessary?

Torrie Moore
Concept Engineering Limited
torrie@concept-eng.co.nz