Anonymous_User Absent Member.
Absent Member.
1647 views

eDir Password Hashes

Hi,

Is there already a fully supported way to use better hashes than md5 for
the eDirectory passwords (eh salted sha-512)?

Universal Password and NDS Password is not an option for the client, it
needs to be

- case sensitive and special characters supported
- be able to set password policies
- NON-Reversible by design (!)
- 'modern' hash functions

thx,

Thorsten
Labels (1)
0 Likes
7 Replies
Knowledge Partner
Knowledge Partner

Re: eDir Password Hashes

On 07/27/2017 07:35 AM, Thorsten wrote:
> Hi,
>
> Is there already a fully supported way to use better hashes than md5 for
> the eDirectory passwords (eh salted sha-512)?


To be clear, you are referring to "Simple Password" stuff, since that is
the only way to import passwords from a third-party and have them use
something.

> Universal Password and NDS Password is not an option for the client, it
> needs to be


That's too bad, for them.

> - case sensitive and special characters supported


Hashes, by definition do not allow analysis of any of this, since they are
non-reversible.

> - be able to set password policies


Universal Password, or even NDS Password can do this, because those can be
set and not just imported.

> - NON-Reversible by design (!)


NDS Passwords and Simple Password are.

> - 'modern' hash functions


Simple Passowrd has a documentation change covering what is actually
supported now, and modern stuff is, but it's still only for imports, not
for ongoing password sets.

At the end of the day, there are ways to make this work, but none of them
meet all of their needs using native authentication methods in eDirectory.
You can import hashed passwords, and not just MD5, into Simple Password,
but you cannot have the system set new passwords using those hashes unless
you have some sort of portal which takes the password, hashes it, and then
imports again, which could work I suppose. Alternatively, you could
extend schema and store the hashes in a new custom attribute and then have
your applications that need to perform authentication read that and do the
comparison of user-entered data (hashed) with what is stored in that
custom attribute.

Another option is, again if you control the applications doing
authentication (probably via LDAP), you could actually store the hashes as
the Universal Password (or even NDS Password) so when they authenticate it
just sends the hash as the actual password. Not everybody has this kind
of application control, but it could be easy in some cases.

This is all a lot of work to get around the system that is secure with
Universal Password (UP). The default UP policy does not allow viewing the
passwords, so unless that changes (auditing could catch that pretty
easily), or unless somebody has complete access to eDirectory (meaning
they could also trivially intercept passwords stored as hashes), there is
no more risk of passwords getting out here than anywhere else. The old
(ancient) logic about passwords needs to be changed, and finally is
getting some much-needed coverage, but it's still a slow road to get away
from old ideas about password complexity, password lifetime, password
managers, and the like.

Back on-topic, if you can describe how your customer intends to use
passwords, and why they have those specific requirements, maybe this can
work really easily, but if not at least they can be informed about the
weaknesses they are assuming in their plan.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
skoehler Absent Member.
Absent Member.

Re: eDir Password Hashes

ab, good answer.

Especially when discussing with the Microsoft departments at customers, the argument comes up "eDirectory is weak because it only encrypts the Password, whereas there is no way to get a Password out of AD (besides the Password Filter API or hash attacks, but that's a different Story).
This reduces the security disussion to the storage of passwords (or their hash) in the directory, that's much to less. My arguments go a different direction: make Passwords less important! Why? An example

A web browser calls a Login page where you enter username and Password:
- intercepting the Keyboard may expose the password (USB dongle, recording by mobile device camera...)
- a hacking tool on OS-Level could intercept the password entered/processed
- a browser setting might allow to store the Password(hash) in the browser password store... (which ends up in he user profile on some file system)

Finally the password goes over the wire to the web application server
- did you ever use wireshark to decrypt a SSL/TLS session? Most People don't take the "private" in Private Key serious...

Now the application Server processes the user authentication to the LDAP server
- guess what... once your IP packets passed OSI layer 4, all the stuff is clear text again. The application server could debug-log values entered, when passing them to the applications LDAP client
- The username/password crosses the next wire: application server to LDAP server. Once your hand on the private key of the LDAP Server, it's all yours (and guess what: I just figured out that eDir 9 currently does not support the setting "do not allow to Export private key" for the LDAP server as was in eDir 8.x.).

Ask yourself:
Who controls the User hardware?
Who conrols the User OS and browser setings and the user profile filesystem?
Who controls the application server OS and the web server private keys?
Who controls the application (log level, login page, LDAP client)?
Who controls the LDAP server and it's private key?
That brings us to the implied question of this thread: Who controls eDir and UP policies?
Who controls the IDM engine and policies of your IDM developer?
Who controls the IDM driver certificate privte key and remote loader?
Who controls the target server/system and private key where IDM syncs the passwords to?
Who controls all the stuff that connects to this target system?


What I would recommend besides the "normal" security-stuff like endpoint protection, file encryption, application code review, priviledged account management and stuff like that
- use something more/better than passwords (call NetIQ for Advanced Authentication)
- NEVER EVER sync passwords crossing multiple administrative domains
- Change passwords frequently (daily, hourly? doesn't matter, as long as you use SecretStore in combination with NetIQ Secure Login and Access Manager for SSO 😉
- Have a security control that monitors and resets your Universal Password Policies to a reference value
- Hand out development guidelines a for IDM developers and implement code review for IDM Drivers as part of your Security/QM strategy.
- A readable private key is a compromised key. check /etc/apache2/ssl.key on SLES or /etc/pki/tls/private on RHEL. If you can access the .key files, you know that you can extract passwords from recorded TLS sessions to this Server. If your Java keystores are protected by the password "changeit" - it's time to wake up, isn't it?

Steffen
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir Password Hashes

On 08/24/2017 06:36 AM, skoehler wrote:
>
> Especially when discussing with the Microsoft departments at customers,
> the argument comes up "eDirectory is weak because it only encrypts the
> Password, whereas there is no way to get a Password out of AD (besides
> the Password Filter API or hash attacks, but that's a different Story).


MAD actually has an option to store passwords reversibly also; like
eDirectory, that option is disabled by default. Unlike eDirectory, I do
not know anybody who implements it in order to enable things like password
synchronization, which is a pretty big limitation in the MAD world where
they try to do Identity Management.

> A web browser calls a Login page where you enter username and Password:
> - intercepting the Keyboard may expose the password (USB dongle,
> recording by mobile device camera...)
> - a hacking tool on OS-Level could intercept the password
> entered/processed
> - a browser setting might allow to store the Password(hash) in the
> browser password store... (which ends up in he user profile on some file
> system)
>
> Finally the password goes over the wire to the web application server
> - did you ever use wireshark to decrypt a SSL/TLS session? Most People
> don't take the "private" in Private Key serious...
>
> Now the application Server processes the user authentication to the LDAP
> server
> - guess what... once your IP packets passed OSI layer 4, all the stuff
> is clear text again. The application server could debug-log values
> entered, when passing them to the applications LDAP client
> - The username/password crosses the next wire: application server to
> LDAP server. Once your hand on the private key of the LDAP Server, it's
> all yours (and guess what: I just figured out that eDir 9 currently does
> not support the setting "do not allow to Export private key" for the


This is a moot point since eDirectory 9.x also allows use of ECDHE
ciphersuites out of the box, which invalidates the usefulness of the main
private key entirely. Worded another way, like SSH traffic, you cannot
decrypt the actual application data if it is encrypted with a ciphersuite
using ECDHE which is the norm for eDirectory 9.x.

> LDAP server as was in eDir 8.x.).


In other words, address the probability of risk every applicable, and
chances are very unlikely that the greatest risk is the Universal Password
(UP) when considering all of the other possibilities for information
leakage, and if so, good for you as you probably also know how to keep UPs
secure as they are unless you do something really foolish.

> What I would recommend besides the "normal" security-stuff like endpoint
> protection, file encryption, application code review, priviledged
> account management and stuff like that
> - use something more/better than passwords (call NetIQ for Advanced
> Authentication)


I presume you mean in addition to passwords. Using only a token, a
biometric, or something people do is pretty weak, just like using
passwords alone is pretty weak, but those are actually worse. Biometric
options are good for identifying somebody, but not so great for
authentication entirely.

> - Change passwords frequently (daily, hourly? doesn't matter, as long as
> you use SecretStore in combination with NetIQ Secure Login and Access
> Manager for SSO 😉


You still must authenticate to those systems somehow.

> - A readable private key is a compromised key. check
> /etc/apache2/ssl.key on SLES or /etc/pki/tls/private on RHEL. If you can
> access the .key files, you know that you can extract passwords from
> recorded TLS sessions to this Server. If your Java keystores are
> protected by the password "changeit" - it's time to wake up, isn't it?


Also not a valid argument if your services use ECDHE as they should; sure
those keys should remain private, but more for impersonation concerns than
decryption of data on the wire since asynchronous keys are generated on
the fly when EDCHE is used.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
skoehler Absent Member.
Absent Member.

Re: eDir Password Hashes

good Point with ECDHE. Will have a closer look into it, at least that reduces the risk of traffic sniffing between LDAP Client and LDAP browser.

I know many Consultants that state "A Password should never be reversible and within eDir it is stored in a reversible way, therefor it is bad."
Sure you can configure AD to store reversible (which it doesn't by default and there are many security best practices out there not to do it), but you can't configure eDir to NOT store it reversible. An option here would be great.
Password sync is a different story as it uses nspmDistributionPassword, an attribute that could still be updated by the eDir Server (when hashing the Universal Password).
But that's an option I can switch on or off... like the AD Password filters (but Directory-wide, not server-centric)

I don't want to defend the pro-AD arguments, but search for better pro-eDir arguments 😉

2 years ago I did an enhancement request for that, but it got rejected...

Steffen
0 Likes
skoehler Absent Member.
Absent Member.

Re: eDir Password Hashes

OK we have the NDS Password, but comparing the password policy options, that fails behind AD so much that I even don't mention it...

imo NetIQ should have used the major release to drop NDS Password Support completely and allow hashing UP instead.
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir Password Hashes

On 08/25/2017 05:54 AM, skoehler wrote:
>
> good Point with ECDHE. Will have a closer look into it, at least that
> reduces the risk of traffic sniffing between LDAP Client and LDAP
> browser.


Yes, and it is a huge reason to move to eDirectory 9, or anything based on
OpenSSL 1.x (in addition to the TLS 1.2 availability in general) for all
kinds of services, such as HTTP using the same technologies.

> I know many Consultants that state "A Password should never be
> reversible and within eDir it is stored in a reversible way, therefor it
> is bad."
> Sure you can configure AD to store reversible (which it doesn't by
> default and there are many security best practices out there not to do
> it), but you can't configure eDir to *NOT store *it reversible. An
> option here would be great.


That is not true, as you later corrected; NDS password is the only type of
password enabled by default, even in eDirectory 9.x, and it is not only
non-reversible, it is never sent over the wire during authentication (not
the case with microsoft active directory (MAD), even in a native windows
environment) because it uses public/private keypairs to do everything, and
has since 1993. Sure, this is also going to prevent things like password
synchronization with other systems, but every solution out there which
uses password synchronization in any way by definition must use the
password in its cleartext form at some point.

eDirectory also has a Simple Password option, which is also
non-reversible, but was replaced by Universal Password (UP) because of
greater options making UP worth the replacement.

> Password sync is a different story as it uses nspmDistributionPassword,
> an attribute that could still be updated by the eDir Server (when
> hashing the Universal Password).


I do not think this is going too be a valid argument to anybody who cares.
Either you have the password reversible in this attribute right here, or
in that attribute right there next to it. Either way if you have somehow
compromised the entire system, figured out how to read the DIB, extracted
two other keys, found the value, and then applied the keys to it, you
could conceivably get the user's password out.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
skoehler Absent Member.
Absent Member.

Re: eDir Password Hashes

Agreed... So we need enhanced Password Policy Support on NDS Password then 🙂 - Or did I miss that this is there in eDir 9 already?

My default habit is to enable Universal Password right after the install... Not had a look at NDS Password for years, so you're right it is the default, just almost nobody (I know of) is using it due to limited password policy options.

When hardening an eDir 8.8.8 instance for a regulated environment, I discussed usage of NDS password for admin and service accounts for security reasons (where IT operation sets random strong passwords) but even for these accounts they required an "AD like" password policy - for compliance reasons (you may know, auditors like to tick checkboxes, they don't like discussions and arguments).

The more we talk about, again, the more I miss the feature where I could configure a non-reversible universal password (or have an enhanced password policy on the NDS password, at the end that would be the same).

Steffen
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.