SQL security

[ambarnes]

I know I posted this in a different topic area, but just thought I'd put it in this area too.

For those people who may run their system or shadow it in SQL (we use SQL 2K), make sure to NOT convert or shadow the operator file to SQL. Make sure that file stays in P4.

Once that file is in SQL, all user passwords are out in the open and can be viewed plain text.

If anyone else knows of other files that should stay in P4, please let everyone know.

[tommy]

Actually it applies to any RDBMS not just MS SQL.

[smorice]

Hi,

I've currently open an incident to the support last month for this kind of problem and they told that I can map it and encrypting it.
Once operator is linked to SQL DB you un-map it and on the detail of the field check encrypted for password field. Once it's done you can map operator file to SQL and the passsword will be encrypted (not very complex but not in clear).

[tommy]

To keep it secure You must ensure that noone can read the sc.ini file. The key consisting of a 8 digit number must be stored in sc.ini


In any case I don't think the encryption is good.


In my opinion Peregrine should make a change so the password is always stored as a MD5 hash. If should not be that big a change to implement that.