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

Wilfried Woeber, UniVie/ACOnet wrote:
> 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 :-( )
>   
Why does it matter if people don't have a local copy of the hash? If you
want to modify the mntner object (maybe add a new admin-c) and you can't
remember the hash value, you can just encrypt your plain text password
again and enter a new hash value to the update. It may be a little bit
inconvenient, but not a major problem. I don't think even the password
owner 'needs' to see the hash.

regards
Denis Walker
RIPE NCC
>   
>> 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.
>>>       
>
>