Bill Sommerfeld wrote:
> missed this section the first time around.
>
> On Tue, 2007-07-31 at 23:35 -0700, Alan Wright wrote:
> > The NDMP service would use the NDMP "standard" specified
> > authentication order, which I believe the project team said was
> > try CRAM-MD5, if that fails, use plaintext.
>
> I don't see any way to require the exclusive use of CRAM-MD5 when we
> know that the peer supports it (to avoid a downgrade attack).
The CRAM-MD5 hash is never stored. It is generate at runtime using
the plain text password and a randomly generated challenge key.
A new challenge key is generated for each connection. We need to
to store and recover the plain text password.
The exchange is:
1. Server offers authentication options (plain text or CRAM-MD5)
2. Client selects an option (assume CRAM-MD5)
3. Client requests a connection
4. Server issues randomly generated challenge key
5. Client responds with CRAM-MD5 hash based on chanllenge key
and plain text password
6. Server compares locally generated hash with client supplied
hash
> Using the same keying material with multiple algorithms is *always* a
> bad idea. (especially in this case!). if we support both algorithms
> we should store CRAM-MD5 keying material separately from plaintext
> passwords or password hashes.
>
> (note that an administrator intent on committing this cryptographic sin
> could configure the same value with both algorithms if they needed this
> for interoperability. but we shouldn't make it too easy.)
>
> having distinct "admin-passwd" and "admin-cram-secret" values would be a
> better way.
In either case (i.e. regardless of the negotiated authentication
mechanism) we need to store the plain text password, which we will
encrypt using a reversible encryption algorithm.
Alan
