Re: [ldapext] DBIS - new IETF drafts

[Andrew Findlay <[e-mail]>]

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.

> >> My point of view is that using LDAP binds SHOULD be mandated for
> >> authentication for any new client following any new schema, and exposing
> >> hashes MUST be disabled by default, and explicitly enabled by admins
> >> that needs backwards compatibility. We need to move up the security bar,
> >> and you do that only with appropriate defaults, and new IETF work should
> >> reflect that IMHO.
> >>
> >> Simo.
> 
> +1 to Simo's comment.

Another +1.

I find that showing people the crack-attempt rate tables on
Hashcat's front page usually ups the priority for getting rid of old
hashes... To see the data for Crypt-style hashes you need to go back
in the archive a bit:

	http://web.archive.org/web/20130703144216/http://hashcat.net/oclhashcat-plus/

Comparing those figures (July 2013, based on software from January
2013) with todays is interesting too. The latest hardware they have
tested boosts the crack-rate by another order of magnitude so
traditional Unix-style crypt(3) hashes are probably testable at 600M
attempts/sec, with plain MD5 now at 81000M and NTLM at 140000M...
That means that *every possible* 8-character ASCII password can be
tested against a file of NTLM hashes in 12 hours, or against Unix crypt
in 117 days on a single PC. Real passwords are at least 1000 times
weaker in practice.

In terms of LDAP best practice what this means is:

	Store password data using a modern salted hash that was
	designed specifically for this purpose. Preferably choose
	one that allows the number of iterations to be increased in
	the future. [ I currently favour bcrypt ($2a$), falling back to
	sha512crypt ($6$) or md5crypt ($1$) if that is not available ]

	Use ACIs to prevent access to password storage fields.

	Use all good system-management practices to protect the LDAP
	database, the filesystem, the physical disks, and the backup
	tapes from being copied or stolen.

	Advise users to set much longer passwords than before.
	e.g. a 5-word Diceware password is about 1000 times better
	than the best possible 8-character ASCII password - and a
	lot easier to remember and to type!

	Passwords hashed with weak schemes may be imported as part
	of a migration process provided they are changed within some
	short period of time to be set by a sensible risk analysis.

> > I don't think LDAP binds can be mandated, we can only strongly recommend it. 
> > Given the migration path I have already described, I find it highly unlikely
> > that people will be able to move to LDAP binds and move off CRYPT immediately,
> 
> If your customers have old legacy systems which they won't change at all then
> simply let them run them in a isolated environment with all the old cruft
> around they need for those systems. Sooner or later they have to migrate
> anyway because systems are running out-of-service (e.g. will not receive
> security updates anymore).

I would be a bit more flexible than that. There are often advantages
to loose coupling of the old system to the new one: reduced support
effort, maybe even increased security as passwords actually do get
changed, etc. There are risks though, and these need to be
considered on a case-by-case basis. An obvious example here would be
a system that stores an old Unix-crypt hash alongside a bcrypt one
with both derived from the same data. The old hash is easily
attacked and will expose the first 8 chars of the full password with
very little effort, making it much easier to attack the full
password in the bcrypt hash.

> 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!

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------