Re: DBIS - new IETF drafts
Mark R Bannister <[email protected]> Fri, 10 Jan 2014 14:07:40 +0000
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
On 09/01/2014 17:43, Andrew Findlay wrote: > On Thu, Jan 09, 2014 at 04:22:22PM +0100, Michael Ströder wrote: > >> Mark R Bannister wrote: >>>> Exposing hashes should be a last resort for compatibility reasons only >>>> and should be disabled by default with appropriate ACIs. > Absolutely. You need the LDAP server to support the old-style hashes > to allow for migrating data in, but exposing *any* form of hash > outside your trusted LDAP servers is asking for trouble. > > Every LDAP-aware client system that I have worked with can use the > bind operation as a means to validate passwords, so the only > possible excuse for exporting hashes is temporary support of > migrating systems. If you only allow the export of hashes that are > actually needed by the old non-LDAP systems then at least you are > not making matters worse than they were before the migration. Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords? If it can be done server-side there'll be no problem here and we need never expose the hashes to clients. > <snip> >> IMO any new standard should focus on getting the near future right. > Yes, but that does have to include migrating stuff that is currently > stuck in the technological past! > > Thanks Andrew, I think this point can't be emphasised enough. We must always be aware of how customers are going to be expected to get from A to B. That journey needs to be as simple as possible. If that means supporting extra legacy stuff to smooth the transition, than so be it. Best regards, Mark.