[db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database

Max Tulyev wrote:

> Hi Katie!
> 
> Why not just to hide encrypted password from public view (as it done
> with e-mails)?

Even that is a bad hack which I resent, but eventually I gave in. We had
done a similar thing in the past, with a different attribute, and we had to
roll back.

And we would have to invent just another flag to undo the hiding. This cannot
be kept secret for long, so what?
	(Not doing that would actually require "everyone" to keep a *local*
	 copy of the hash on backup for inclusion in the next update.
	 That's asking for chaos :-( )

> Note that MD5-PW is not much better: I bruteforce it approximately in
> one-two weeks (of course, not any password).

Just have a closer look below, please:
"MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in clear
together with update requests and MD5 is vulnerable to dictionary attacks,
as well..."

While drafting the proposal we *consciously* included that before sending
out the proposal, for exactly the reason you are pointing at.

> Other proposal is to set up TLS/SSL at RIPE mail servers to encrypt
> traffic and to make interception of clear text passwords harder.

While I don't have any objection against implementing TLS/SSL/whatever
*if it adds value*, this is not going to make too big a difference: We
are dealing here with a public database, and in case you need 2 parties
to provide credentials (and both NOT using asy-crypto) then at least 1
party still has to disclose the password/passphrase to the other.

Transport security won't help, really.

The only thing that helps in the long run is moving to asy-crypto.
Let us spend our effort on a real solution.

Wilfried.

> Katie Petrusha wrote:
> 
>>Dear colleagues,
>>
>>Here follows the proposal to deprecate CRYPT-PW authorisation in mntner objects in the RIPE Database. Comments would be appreciated.
>>
>>Background and motivation
>>-------------------------
>>
>>In the RIPE Database there are several authorisation types currently supported:
>>CRYPT-PW, MD5-PW, PGPKEY and X509. These authorisation types define what kind of
>>authorisation tokens can be used in "mntner" objects.
>>
>>CRYPT-PW authorisation type is based on UNIX crypt() functionality and is
>>vulnerable to both dictionary and brute force attacks given the fixed password
>>length and lack of cryptographic strength given today's computing power.
>>While maintaining and protecting objects in the RIPE Database is the 
>>responsibility of the respective maintainer, the RIPE DB WG agreed that it's 
>>the responsibility of the community to ensure that only appropriate tools 
>>and algortihms are used and maintained.  
>>
>>Since CRYPT-PW does no longer fulfill this requirements with the reasons 
>>given above, the WG also agreed to phase out CRYPT-PW. PGPKEY and X.509 
>>have been the recommended authentication schemes for some
>>time (http://www.ripe.net/db/support/security/security.html)
>>
>>MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in
>>clear together with update requests and MD5 is vulnerable to dictionary attacks,as well. Still, MD5-PW will not be phased out together with CRYPT-PW, since
>>at least the dictionary attack can be prevented by chosing passwords or
>>pass phrases of appropriate length and entropy. MD5 offers a short path
>>of migration away from CRYPT-PW without major change in processes. LIRs
>>should, however, seriously consider a migration towards a public key based
>>authentication scheme (PGPKEY or X.509). The MD5-PW method will be addressed
>>separately.
>>
>>We propose to deprecate the CRYPT-PW authorisation step-by-step.