Hi, Denis is right, the problem isn't only RIPE access and I aggre DB needs to be redesigned in terms of security - we're talking not only about LIR portal and RPKI dashboard, which caused issue with Orange. If you break objects in DB in similar manner (as-sets, route objects), you'll cause similar outage - just because many upstreams and IXP use these data to build their prefix filters. Maybe the destruction will not be so fast... For some methods (restAPI) you need password linked to maintainer object. And all passwords here are still stored in MD5! Yes, this is year 2023. There's no other option [1]... All this is one big ticking bomb... I don't want to guess what could happen if the internal in case of internal RIPE database leak. Just because we're still storing some passwords in prehistoric way. It's not only about LIR accounts, risks are also hidden in maintainer objects, which can be used outside LIR portal. And it's out of reach of one working group. Trivialization of risks is highway to hell. And there're more things, which needs better protection - not only RPKI ROAs. - Daniel [1] https://apps.db.ripe.net/docs/Authorisation/Authorisation-Model/#solving-aut... On 1/4/24 21:24, Jim Reid wrote:
IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-)
The first priorities should be to plug the security issue(s), secure the exposed LIR accounts and do an audit/impact analysis. Discussions about next steps can wait until these have been done. Those next steps may well include a redesign of the RIPE database. Though I think other things would need attention before that: revising the RIPE Access requirements, introducing 2FA, assessing the report about the latest breach, etc.
It seems premature to debate changes to the database when it’s not yet clear what needs to be done. That may well be clear to you Denis. But perhaps your thoughts will need a reassessment in light of this security breach.