Earthdata Login Password Rotation

[dem1]

Hi,

We received this email "Beginning in January 2024, all Earthdata Login User Accounts will be required to update their password once every 60 days in order to remain active."

Is there a way to avoid to have to manually update password for our automatically download chains? Maybe using an appkey? or is it also impacted by the rotation?

Thanks,
Julien

[planet_downloader]

I second that. It would be really nice to have something in place for automatic downloaders.
When will the first "rotation" going to happen? Do we have to change our password just before 2024-01-01 to reach 2024-03-01 or are we directly locked out when we haven't changed it for a long time.

[smykytyn]

This policy is extremely misguided - a relic of the late 1990s maybe. Even ChatGPT know better - see following.


"ChatGPT
Forcing users to change their passwords every 60 days was a commonly recommended security practice in the past. The idea behind this approach was to mitigate the risk of compromised passwords. However, current best practices and research suggest that this strategy might not necessarily provide the intended security benefits and can even have some drawbacks:

User Behavior: Frequent password changes often lead to predictable patterns or weaker passwords as users struggle to remember new ones. They might resort to slight modifications or write them down, which can compromise security.
Reduced Security: Paradoxically, frequent password changes may lead users to choose weaker passwords or reuse variations across multiple accounts, making them more vulnerable to attacks.
Increased Help Desk Load: Frequent password changes can increase the load on IT help desks due to users forgetting passwords or experiencing other login issues.
Phishing Risks: Users might become more susceptible to phishing attacks if they receive frequent legitimate-looking password change requests, making it harder to discern actual threats.
Focus on Other Security Measures: Modern security practices emphasize the use of multi-factor authentication (MFA), strong and unique passwords, and monitoring for suspicious activities rather than just focusing on password changes.
Instead of forcing frequent password changes, it's recommended to emphasize the following practices:

Strong, Unique Passwords: Encourage users to create strong, unique passwords that are difficult to guess or crack, using a mix of characters, numbers, and symbols.
Password Managers: Promote the use of password managers to help users generate and securely store complex passwords for different accounts.
Multi-Factor Authentication (MFA): Implement MFA wherever possible as an additional layer of security beyond passwords.
Regular Security Training: Educate users about phishing threats, password hygiene, and the importance of maintaining good security practices.
Monitoring and Response: Employ systems to monitor for unusual activities and respond promptly to potential security breaches.
While the idea of frequent password changes aimed to enhance security, it's important to reassess strategies in light of current research and evolving security practices to ensure a more effective and user-friendly approach to safeguarding accounts and sensitive information."

[wxflights]

Agreed. This is an extraordinary terrible policy. No other private or even government organization does this. This policy will effectively make it impossible to use the service for anyone programmatically accessing data. They must fix this, otherwise they are denying access to their users! Email support@earthdata.nasa.gov and let them know!

[planet_downloader]

Good idea, I filed a ticket. At Earthdata they have to be aware that there are a lot of people downloading the data in an automated way.

[mstartzel]

Hey all, thanks for taking the time to write in.

We hear your concerns that the new 60-day password expiration seems to contradict NIST recommendations. It’s true that NIST does not want limits on length of time you may have a password, but to do that they also assume other security layers are in place (much shorter session duration, heavily rate limited login attempts, much broader user of captchas, longer passwords with sufficient entropy, mandatory 2Factor, etc).

The 60-day requirement comes from the NASA Organizationally Defined Values for authenticator management, which states:
…for a memorized secret when centralized authentication is used and:
· Authenticator Assurance Level 1 (AAL1) is asserted: a one day minimum and a 60-day maximum;…

The date of the first password rotations will be published on the EDL home page, as well as in additional upcoming mailers - you can also count on receiving 10-day, 5-day, and 1-day expiration notice emails prior to each password expiration.

Thanks for reaching out,
Mitch
Earthdata Operations

[dem1]

Thanks for the answers, so do you confirm that the appkey method will also have a 60-day expiration, and that there will be no other way to automatize the password refreshing?
If this is the case I confirm that this change will put a big constraint on all existing services which automatically download your products, like Copernicus, GlobColour, etc...

[mstartzel]

User tokens should continue to have their expiration date honored regardless of password expiry status - but of course, you will still need an up-to-date password to generate further tokens. There are currently no plans for allowing automation of password rotations.

[wxflights]

Unfortunately, the current App tokens expire 60 days or so after creation. In it's current state it's not a functional alternative. This expiration should be much greater.

[OB ODPS - towens]

In the past we have been told that Earthdata Login was for bean counting only and not to be used for user authentication.

Tommy