Re: shared secret vulnerability

[Paul Funk <paul@funk.com>]

Joshua,

Yes, widespread use of the same secret makes it less likely
to stay secret.

One of things the amplification draft discusses is use of a salt
to allow it to be easier to use different shared secrets on different
devices. The salt is set by the administrator and defines the
minimum entropy of all shared secrets derived from it. Each
technician can then make up different precursor secrets for
different devices; these can be much weaker, since the salt
entropy is added to the entropy of the precursor.

Note that the salt as used here is has a different purpose than
as defined in PKCS-5. It is not random data generated for each
use of a secret and displayed as clear text. It itself is kept
secret. In fact, it's best if the salt is a closely held secret of
the administrator, and baked into a utility that technicians can
use when they amplify the precursor secrets.

Paul

Joshua Wright wrote:
Paul Funk wrote:
> The idea is that you take an ordinary secret, hash it many times,
> and get a resulting "amplified" shared secret that multiplies the
> difficulty of attack by the number of times it has been hashed. The
> draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
> bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a password 
such as the RADIUS secret, it does not resolve the issue of a widespread 
shared secret distributed throughout an organization. Without a mechanism 
in place to regularly change the secret, the use of shared secrets in this 
fashion is reminiscent of WEP pre-shared keys. As most people are painfully 
aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to the 
shared secret that will prolong a brute-force attack. However, I do not 
believe that this is effective at resolving weak authentication between the 
RADIUS authentication server and NAS.


-Joshua Wright
jwright@sans.org or
jwright@hasborg.com


--
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/



Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>