Please Read: Significant Update Planned, Migrating Forum Software This Month

See more
See less

Reversible Encryption on the enterpise: some considerations

  • Filter
  • Time
  • Show
Clear All
new posts

  • Reversible Encryption on the enterpise: some considerations

    Hello Everyone

    I have a doubt with Reversible Encription. We all know Microsoft suggest not to activate this setting on a Domain Policy because it is a great risk since passwords are stored in NTDS.DIT either in a secure hash and in a reversible hash (and also we all know this setting can be useful only with MACs or with digest auth, we also know this setting can be found at single user account level, so there's no need to activate this setting doamin wide).

    Well... I am not so sure this is an effective security risk and let me explain why: Which is the actual risk for passwords to get compromised? Let's imagine a common situation with an enterprise with many sites and a single DC spread across sites; every IT on site doesen't get Domain Admin password but just a simple delegation on AD. So every site has 1 DC in place, but inaccessible with interactive logon; also this DC is vulnerable to brute password reset as we know, but is not able to reset this password without Central IT to be warned (Audit of course but also Domain Admin immediately realizes that his password has changed).

    So, if I have on my Enterprise the Rev.Pwd set with a Domain Policy, how can a single person at branch site get this password?
    Well, let's imagine this person is also deleagted to backup my DC. Can he restore the system state on another isolated DC? Of course he can. But then? Is there any utility that can decript the password stored in NTDS.DIT if Rev.Pwd is enabled? I still don't know it... and also I've never heard of people who has been able to decipher password even if Rev.Enc. was enabled. Utilities like LC4 open SAM, not NTDS.DIT.

    The fact that gets me mad is that I am an external consultant, and I've seen one great enterprise (over 500.000 of users with a 150 DC spread across sites) with this setting enabled by Microsoft consultants at domain level... I don't know the reason but I ask myself.... how can this be? Arent they afraid of Domain Admin PWD to be discovered? Haven't we ever read NOT TO ACTIVATE this setting on every Microsoft Document?

    Am I completely wrong o mad?

  • #2
    Ehm, little typo.
    LC4 does open AD database, I forgot..... it is not able to read rev.enc. hashes. It only reads NTLM hash saved in database..

    BTW the rest of my considerations doesn't change


    • #3
      Lets see... First of all, account policies can be set ONLY at domain level, hence if you need rev. enc., your only option is to do it for the WHOLE domain.
      You can not define rev.enc. policy at OU level.

      Now why people do enable it ? You need this setting for NT or W2K RRAS/IAS servers to be able to do CHAP and EAP authentication:

      Now, as I see it, the real problem is not elevating permissions, but stealing someone's identity. If you have been delegated control over some user accounts, and you have read access to userPassword attribute (or you can grant yourself this kind of access by altering ACL), you can potentially decrypt the user password and use someone else's identity without him knowing that (you did not change the user password).

      Now about your comments on how to break into AD and elevate permissions to Domain/Enterprise Admin: you need to understand that "physical access to DC" = "you have full control over the AD".
      Do not elude yourself, if you do some searching in this forums, you will probably find this thread:
      and this article by Daniel:

      You might also want to check the following thread at mailing list:

      As you can see, all you need is physical access to the DC and couple of downloadable tools.

      Moreover, there are even simpler ways to gain control over DC using modified GINA dll or 3rd party tools.

      At the end of the day you should better ask yourself a very simple question: do you trust the people who have any kind of privileged access to the DCs ? If the answer is "No", then you should reconsider the level of privileges of the site/ou/backup/service admins...
      Guy Teverovsky
      "Smith & Wesson - the original point and click interface"


      • #4
        Sorry Guy, but I think you didn't get the point of my thread

        I know physical access = full control over AD but I was simply referring to DECIPHERING PASSWORD!
        I am not talking about gaining full access to AD. I know how to do it.
        Every single thread you refer to, point to the fact that Domain Admin passwords can be reset. And I know this goal is so easy to reach.
        I'm not afraid by this fact, because if a so-called "trusted administrator at branch site" reset my domain admin password I immediately find it out!

        What I am pointing is: which is the ACTUAL risk if my enterprise has set Rev.Enc. domain wide and for some obscure reason I can't modify it?
        Can a "trusted site admin" in some way DECIPHER my domain administrator password?

        I was pointing that I have never heard about some way to decipher passwords stored in AD even if rev.enc. was enabled, and even if Microsoft states on every document about huge risks of this setting.


        • #5
          OK... You are right. I took it somewhere else and I apologize for drifting away.

          I have turned the google upside down (I guess you have already done that) and came up with nothing, but I did find some references to the need to enable rev. enc. when synchronizing passwords across directories via some metadirectory applications (e.g. DirSync). So despite not being able to find any proof of concept, I think it would be a rather educated speculation to assume that products that are capable of performing password synchronization across directories do accomodate the logic for deciphering the passwords stored with rev. enc.

          The other way to look at it, would be the fact that if you have a very strict password policy (let's say you require 16 chars-long passwords or passphrases and are enforcing password complexity), you might end up (assuming you have been able to obtain offline copy of the DIT) with LC running for ages.
          Having the passwords in reversible form would require a very simple (linear ?) deciphering algorithm.

          Actually, I think it would not require very much effort to disassemble the algorithm used to create reversible hashes by setting up your own AD and debugging the OS when setting someone's password while rev. enc. is enabled. Personally have never done that, but I do not see any obstacles that could get in the way of a good programmer.

          Good topic ! I'd be glad to hear what others have to say about it.
          Guy Teverovsky
          "Smith & Wesson - the original point and click interface"


          • #6
            Originally posted by Guy (Antid0t)
            I have turned the google upside down (I guess you have already done that)
            Of course I did it too And also foud nothing interesting about it.
            For example....I expected to find the algorithm used for encription (it would be great to discover one day that it is a simple base64 decoding huh? )

            Originally posted by Guy (Antid0t)
            Having the passwords in reversible form would require a very simple (linear ?) deciphering algorithm.
            That's what I expect from "reversible encryption" words.

            Originally posted by Guy (Antid0t)
            Personally have never done that, but I do not see any obstacles that could get in the way of a good programmer.
            Sure, and my question is: isn't it strange that no-one has ever tried to do this before?