Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 6006 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Level of security on user password in iconn.cfg and iconnlocal.cfg

Damian

I am currently investigating the method in which we allow users to authenticate against our web update server for Sophos Antivirus, we are currently using Sophos Antivirus 7.6.20.

From the clients perspective I notice that the username and password gets stored locally in clear text in the files, even though the password seems to be altered.

C:\ProgramData\Sophos\AutoUpdate\Config\iconn.cfg

C:\ProgramData\Sophos\AutoUpdate\Config\iconnlocal.cfg

Can you confirm to me what level of level of security is used to secure the password, (Encryption , Hash or Encoding?)

:4231


This thread was automatically locked due to age.
  • 0

    Hello Damian,

    the term for the method used is obfuscation, it is of course reversible and just for hiding the credentials from prying eyes. What is your concern?

    Christian

    :4260
  • 0

    Hi,

     

    It doesn't appear to be a secure method of storing the password, which is likely a privileged account in many environments. Is it simply a base64 value of some hex representation of the password broken up into 8 character boundaries? Please confirm.

     

    Cheers - Rob

  • 0 in reply to Rob Dee

    Hello Rob,

    first things first
    likely a privileged account
    iconn.cfg contains the credentials for accessing the update share. By default this is the so-called Sophos Update Manager account that has limited rights. Of course you could consider an account that is allowed to access the share privileged but commonly an account with these rights isn't called privileged. If it has indeed any elevated rights then this is a misconfiguration (and although I've heard of installations where this is the case it's IMO definitively not likely).

    a secure method of storing the password
    there is no secure method of storing data (password, key, whatever) needed to authenticate against a service(server. Do not confuse this with data stored on the server to verify a client. 

    Having said this, the actual implementation is unimportant (you've noticed that if you decode the base64 password value the result is not an ASCII string) as it has to be reversible.

    Christian

Unfiltered HTML