Hi Katie! Why not just to hide encrypted password from public view (as it done with e-mails)? Note that MD5-PW is not much better: I bruteforce it approximately in one-two weeks (of course, not any password). Other proposal is to set up TLS/SSL at RIPE mail servers to encrypt traffic and to make interception of clear text passwords harder. 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.
Affected objects ----------------
There are currently ~3500 mntner objects in the RIPE Database that have only CRYPT-PW authorisation. There are about 300 mntner objects that have mixed authorisation of CRYPT-PW and some other authorisation types.
Plan ----
1. Gather mntner objects: group A: only CRYPT-PW authorisation group B: CRYPT-PW and (PGP or X509 or MD5) authorisation
1a. E-mail the contacts of those mntner objects (notify, admin-c, tech-c, mnt-nfy) to notify them about the coming change.
1b. notify the DB-WG mailing list
1 month later:
2. Modify the RIPE Database software: 1) reject any change to mntner object that adds new CRYPT-PW. 2) show a warning if CRYPT-PW was used during authorisation. 3) show a warning if object being updated still contains (existing) CRYPT-PW.
2a. E-mail the contacts of the mntner objects (notify, admin-c, tech-c, mnt-nfy) notifying them about the change and the next steps.
2b. notify the DB-WG mailing list
1 month later:
3. Modify the RIPE Database software: 1) disable CRYPT-PW in the syntax 2) disable CRYPT-PW in authorisation
3a. Modify mntner objects. group A: auth: is changed to MD5-PW, new password generated. group B: auth: CRYPT-PW is changed into "remarks" line "remarks: "your object was modified due to CRYPT-PW deprecation" is added
3b. Notify the contacts of the mntner objects: group A: explanation about the changes done, and URL with details on how to 'recover' the locked mntner object (similar to NONE deprecation process)
group B: explanation about the changes done
3c. notify the DB-WG mailing list
4. Finished.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)