Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 10 subscribers
  • Views 19332 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

Sophos UTM 9 Password Storage

Alk Sadkla

Hi there,

 

while using the API, I figured out that passwords for internal users are stored as md4-hashes.

According to Wikipedia: "As of 2007, an attack can generate collisions in less than 2 MD4 hash operations" [1]. That was 10 years ago...

 

Is there any possibility to change the hash algorithm to something useful / secure?

I know that I can use alternative authentication backends, but that's explicitly not what I want.

 

Thanks in advance.

Best,

Alk

 

[1] en.wikipedia.org/.../MD4



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Karlos

    I'm sorry, but that's not a very good argument.

    First of all, if it didn't matter, why not simply store the passwords plaintext? I'm sure I don't need to explain why that's a bad idea.

     

    Also, we all know that users like to reuse passwords. So, let's assume a system that has to automatically create networks and users on the firewall. For this, it requires an API key (with admin privileges, because of the user creation).

    If this system is compromised, the adversary can (obviously) modify arbitrary settings in the firewall and gain access to other parts of the network, which is bad enough.

    But instead of telling your customers "Hey, we messed up and an attacker temporarily gained access to some parts of the network (s)he wasn't supposed to.", it's "Hey, we messed up and an attacker temporarily gained access to some parts of the network (s)he wasn't supposed to. Also, all passwords were stolen and if your users aren't very security-minded people, all your confidential business information that was stored in mails etc. has now been stolen.". Alternatively, the passwords may be used to gain further access to (now accessible) systems.

    Also, all passwords are unsalted (not that it matters when using md4).

     

    I'm asking you to seriously reconsider this decision.

  • 0 in reply to Alk Sadkla

    Hi  

    We understand your concern. The best thing for you to do is to submit a feature request here

    Our product team will take a look. Thanks Alk.

    - Karlos

    Karlos
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.
  • 0 in reply to Karlos

    Hi  

    done, see https://ideas.sophos.com/forums/17359-sg-utm/suggestions/31262554-secure-up-to-date-password-storage-for-internal

    It feels kind of sad that basic security best-practices have to be requested as "features" though... I hope the product team will act upon this issue.

     

    Thanks for your support.

    Alk

  • 0 in reply to Alk Sadkla

    Hello Alk,

    are these only local passwords that are stored this way or ist there also some caching of passwords of backend systems involved?

    I discovered recently that wen switching on debug mode all passwords (firewall and backend systems) are printed to the logfiles in cleartext. This can easily be switched on with a one liner by all administrators. The sophos support did not mention it to my collegue when he began troubleshooting with them. I was discovering it after the ticket processing was very slow and I decided to have a look on the logfiles on my own.

    Best regards,

    Bernd

  • 0 in reply to BeEf

    Good question.

    As far as I can tell from the API, the passwords are not cached for remote users. (The md4hash property is empty).

    However, if you use a remote authentication backend, you have to add an account to authenticate with.

    The credentials for this account are stored in plaintext (!) and can be accessed via the API.

Unfiltered HTML