Hi! If to be seriously, I'm showing until weak schemes will be exist, people (even so serious) *WILL* use it. Education will *NOT* helps to solve the problem (so, try ;) ). I agree better is set off ANY password authorization. We can do it at least step-by-step, but leave it alone is the worst thing we can do. Potapov Vladislav wrote:
Hi! I don't understand WHAT IT'S PROVES? Or you decided to say something only to be shown?
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev Sent: Thursday, October 05, 2006 2:16 PM To: db-wg@ripe.net Subject: Re: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
Hi!
Come on, begin your education career from your FSB (ex-KGB if somebody don't know) colleagues:
inetnum: 213.24.76.0 - 213.24.77.255 netname: RT-CLNT-FSB-RF descr: Federal Security Service of Russian Federation descr: 3/6 Lubyansky Proezd Moscow 103045 country: RU admin-c: DIP2-RIPE admin-c: ANH8-RIPE tech-c: ANH8-RIPE tech-c: DIP2-RIPE status: ASSIGNED PA mnt-by: AS8342-MNT source: RIPE # Filtered
person: Dmitry Pravikov address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2248374 phone: +7 495 2248374 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: pravikov@fsb.ru nic-hdl: DIP2-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes
person: Alexander Holushco address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2244441 phone: +7 495 2244441 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: root@fsb.ru nic-hdl: ANH8-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes
% Information related to '213.24.0.0/16AS8342'
route: 213.24.0.0/16 descr: RTCOMM-RU origin: AS8342 mnt-by: AS8342-MNT source: RIPE # Filtered
As we can see - there is *NO* mntner at all at *-c: objects! ;-)
Potapov Vladislav wrote:
Hi,
From: Gert Doering [mailto:gert@space.net] Changing from CRYPT-PW to MD5-PW doesn't incur any operational changes, and doesn't require key management and crypto of any sort, but *will* improve security.
No "operational changes"? Let's look at the plan to get an image that it's not so "problemless". I don't speak about RIPE resources which should support this change. About security: there was several opponents of your view already. I'm adding myself to them.
From: Gert Doering [mailto:gert@space.net] Security issues in the IRR DB impact all of us (like "fake objects, use that to leverage a routing attack").
Let's not say fairy tales about that. I have asked about REAL LIFE problems with the scheme. Nobody has answered. As for security issues... I think the better way to do this things is to educate people, convince them to have better way of security. Up to now it is only "small group words" and 3500 usages...
I'm against the proposal.
Vladislav Potapov Ru.iiat
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)