If you're committed to mandatory API key expiry may I suggest delaying the MD5-PW removal until after OAuth2 is in place?
That way we don't force people to change to something that they might only want to use for a year or so before OAuth2 is there. -Cynthia On Wed, 23 Oct 2024, 15:24 Felipe Silveira, <[email protected]> wrote: > Dear Job, all, > > Thank you for your suggestion. > > Implementing an API for API key management would require a significant > effort. Looking ahead, we plan to introduce OAuth 2.0 authentication, which > will provide automation, including key rollover. We therefore believe it > would be more efficient to prioritise the implementation of OAuth 2.0 > rather than duplicating similar functionality for API keys. > > We appreciate your understanding and remain open to any further > suggestions or discussions. I will be in Prague next week, so feel free to > approach me (or anyone from my team) if you'd like to chat further about > the best way forward. > > Kind regards, > > Felipe Victolla Silveira > Chief Technology Officer > RIPE NCC > > On Fri, 11 Oct 2024 at 00:38, Job Snijders <[email protected]> wrote: > >> Dear Felipe, RIPE NCC, >> >> Thank you for your efforts to improve account security for LIRS. I >> appreciate the approach to tie API keys to individual RIPE NCC Access >> accounts. I imagine the approach might help improve employee >> off-boarding processes. >> >> I want to comment on one specific aspect that I'm not entirely >> comfortable with: >> >> On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote: >> > Secondly, we will implement mandatory API key expiration dates. We >> > will allow the user to choose the expiry date when creating a new key, >> > but expiry cannot be more than one year. We will notify the RIPE NCC >> > Access user in advance by email and on our web interface(s), if any of >> > their API keys are due to expire soon. >> >> I don't see the security advantage here. The "expires after a >> year"-approach means that once a year API users need to copy private key >> material from RIPE portal to internal tooling, get the change approved, >> test the results, etc. >> >> Such events are are both a security sensitive operation and also a >> potential operational problem when the API key isn't replaced in time. I >> fear I see a potential for folks ending up working under time pressure. >> If the expiry happens to coincidence with a change freeze it'll be >> unwelcome. >> >> Introducing an ability which allows users to set expiry dates on API >> keys seems fine, but the maximum expiry of 1 year seems to short. I'd >> prefer it if the expiry moment is left as a decision to the user. >> >> Kind regards, >> >> Job >> > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with > the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
