[db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
- Previous message (by thread): [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
- Next message (by thread): [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Denis Walker
denis at ripe.net
Wed Oct 4 18:05:10 CEST 2006
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. >>> > >
- Previous message (by thread): [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
- Next message (by thread): [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]