Hi Ed, On 18 Sep 2024, at 17:39, Edward Shryane wrote:
At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan. […]
Thanks for addressing this. The concept of having public data, with authentication for updating, where the hashed passwords are part of that public dataset, is an awful design. Made for a different time when MAIL-FROM also counted as “authentication”. I have also been addressing this in IRRDv4, the other actively maintained authoritative RPSL database software. In broad strokes, we’ve added something similar as an option, where users are authenticated through a portal with a separate auth database[1]. IRRD’s requirements are rather different than RIPE db, as it is generic software used by different deployments that all have their own policies and requirements. One feature I have not seen in this discussion: someone with the ability to change a mntner can lock out other existing users from a mntner, if they can remove all other auth methods (96% of RIPE mntners are listed in their own mnt-by). While there is a recovery process, it is considerably more impactful. To reduce that risk, IRRD has two levels of users associated with a mntner, and the more restricted one can modify any object, except the mntner object itself. IRRD’s API keys can never change the mntner object they are associated with. So that narrows the scope for mntner takeover. Perhaps something to consider for RIPE db as well. Sasha [1] https://irrd.readthedocs.io/en/stable/admins/webui/