Discussion on HTTP password rotations

[Xiaohan Jiang Chen]

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

We can see that this solution would require changes to the core Gerrit server. Therefore I wanted to start a discussion first before making any change.s I wonder if you have any thoughts on this potential solution or any suggestions for better ways we could achieve this functionality.

Thank you for your time and consideration.

[Sven Selberg]

On Monday, June 17, 2024 at 7:57:57 AM UTC+2 Xiaohan Jiang Chen wrote:

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

Could you upload a design document describing the feature?
Process described here.

[Luca Milanesio]

On 14 Jun 2024, at 17:09, Xiaohan Jiang Chen <xiaohan....@arm.com> wrote:

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

I believe we just need a way to have a user with multiple passwords, exactly as we have a way to have a user with multiple SSH keys.

“old” prefix looks a bit short-sighted.

Also I like the approach of setting an expire date,  I would also argue that we do need a way to configure the algorithm as different companies may have different security constraints.

We can see that this solution would require changes to the core Gerrit server. Therefore I wanted to start a discussion first before making any change.s I wonder if you have any thoughts on this potential solution or any suggestions for better ways we could achieve this functionality.

I have the impression that it can be implemented as a plugin, which could easily become a core plugin.

Alternatively, the right way to go is a design document, which could be a much longer path to follow.

Up to you, for which way you’d like to go.

Luca.

[Sven Selberg]

On Monday, June 17, 2024 at 10:27:38 AM UTC+2 Luca Milanesio wrote:

On 14 Jun 2024, at 17:09, Xiaohan Jiang Chen <xiaohan....@arm.com> wrote:

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

I believe we just need a way to have a user with multiple passwords, exactly as we have a way to have a user with multiple SSH keys.

“old” prefix looks a bit short-sighted.

"previous"?

 

Also I like the approach of setting an expire date,  I would also argue that we do need a way to configure the algorithm as different companies may have different security constraints.

Expire date for all http password, "present" and "previous" would 
I.e.

1. Create password, gets expire-date $DATE.

2. At $DATE-time, reminder to change password.

3. Creating new password moves previous password to "previous" together with expire date $DATE
4.1 (only 1 "previous") Both passwords are valid up until $DATE or the password is changed again (previous is kicked out of "previous")

4.2 (many "previous") All passwords are valid up until their expire date or explicitly removed.

[Xiaohan Jiang]

Thanks for you reply, really appreciate your feedback!

If a plugin is the way to go, I believe that changes to the Gerrit codebase would still be required, right? Particularly how PasswordVerifier would be extended to handle checking for multiple passwords. Additionally, by implementing a plugin do you mean storing these "old" passwords separate from the externalIDs?

[Luca Milanesio]

On 17 Jun 2024, at 10:58, Xiaohan Jiang <xiaoh...@gmail.com> wrote:

Thanks for you reply, really appreciate your feedback!

On Monday 17 June 2024 at 09:27:38 UTC+1 Luca Milanesio wrote:

On 14 Jun 2024, at 17:09, Xiaohan Jiang Chen <xiaohan....@arm.com> wrote:

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

I believe we just need a way to have a user with multiple passwords, exactly as we have a way to have a user with multiple SSH keys.

“old” prefix looks a bit short-sighted.

Also I like the approach of setting an expire date,  I would also argue that we do need a way to configure the algorithm as different companies may have different security constraints.

We can see that this solution would require changes to the core Gerrit server. Therefore I wanted to start a discussion first before making any change.s I wonder if you have any thoughts on this potential solution or any suggestions for better ways we could achieve this functionality.

I have the impression that it can be implemented as a plugin, which could easily become a core plugin.

Alternatively, the right way to go is a design document, which could be a much longer path to follow.

 

If a plugin is the way to go, I believe that changes to the Gerrit codebase would still be required, right?

I don’t think so: a plugin would be able to do the job without having to change Gerrit.

Particularly how PasswordVerifier would be extended to handle checking for multiple passwords. Additionally, by implementing a plugin do you mean storing these "old" passwords separate from the externalIDs?

Plugins can add their external ids, see the GitHub plugin as an example.

Luca.

Up to you, for which way you’d like to go.

Luca.

-- 
-- 
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/9784196c-525a-466f-bb64-07be8e0900acn%40googlegroups.com.

[doug.r...@cirata.com]

Folks:

On Monday, June 17, 2024 at 4:27:38 AM UTC-4 Luca Milanesio wrote:

On 14 Jun 2024, at 17:09, Xiaohan Jiang Chen <xiaohan....@arm.com> wrote:

Hi mantainers,

I am writing to follow up on a previous discussion regarding HTTP password tokens (reference: https://groups.google.com/g/repo-discuss/c/UVEmpQOlXJQ/m/lGSUvtKdAQAJ). 

Currently generating a new HTTP password overwrites the old one. This can disrupt CI systems and other services that rely on the old password for authentication. A previous suggestion involved maintaining the old password validity for a specific timeframe (TTL) after generating a new one.

To address this issue, I propose introducing a new field named `oldPassword` within the `ExternalIDs` entity. When a new HTTP password is generated, the new password replaces the existing `password` field and the old password is moved to the newly created `oldPassword` field. During authentication, the system would then check if the provided password matches either the current `password` or the stored `oldPassword`. Additionally, the `oldPassword` would have an associated TTL stored within `ExternalIDs` to ensure its automatic expiration.

I believe we just need a way to have a user with multiple passwords, exactly as we have a way to have a user with multiple SSH keys.

“old” prefix looks a bit short-sighted.

Short-sighted indeed.  If the reason for generating a new password is because the prior password was compromised then migrating it to a "old, still active" status is counter-intuitive for most admins and will result in a continuation of the compromise. Requiring an admin to generate a new password 2X also seems counter-intuitive.

Far better to enable multiple passwords including a possible expiration date.

This does bring up the whole conversation of password complexity, aging, etc.  Per Luca's note below about security constraints.

Cheers.

Doug

[Xiaohan Jiang]

Hi maintainers,

I am trying to write a plugin as suggested above and ran into an issue where I'm unable to bind my custom implementation of `PasswordVerifier` from the plugin because the binding is already set in the `ExternalIdModule`.

Do you have any suggestions on how to resolve this conflict?

Many thanks,

Xiaohan Jiang

[Luca Milanesio]

On 26 Jun 2024, at 16:57, Xiaohan Jiang <xiaoh...@gmail.com> wrote:

Hi maintainers,

I am trying to write a plugin as suggested above and ran into an issue where I'm unable to bind my custom implementation of `PasswordVerifier` from the plugin because the binding is already set in the `ExternalIdModule`.

Look at how I’ve implemented the authentication on the GitHub plugin at [1].

You have to implement a filter managing the basic authentication and then propagate the authenticated user back to Gerrit.

HTH

Luca.

[1] https://gerrit.googlesource.com/plugins/github/+/refs/heads/master/github-oauth/src/main/java/com/googlesource/gerrit/plugins/github/oauth/OAuthWebFilter.java?autodive=0%2F%2F

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/635ab276-3377-4be0-9101-0cdfe9008deen%40googlegroups.com.

[Xiaohan Jiang Chen]

On Wednesday, June 26, 2024 at 5:13:12 PM UTC+1 Luca Milanesio wrote:

On 26 Jun 2024, at 16:57, Xiaohan Jiang <xiaoh...@gmail.com> wrote:

Hi maintainers,

I am trying to write a plugin as suggested above and ran into an issue where I'm unable to bind my custom implementation of `PasswordVerifier` from the plugin because the binding is already set in the `ExternalIdModule`.

Look at how I’ve implemented the authentication on the GitHub plugin at [1].

You have to implement a filter managing the basic authentication and then propagate the authenticated user back to Gerrit.

 

It seems that the plugin is storing credentials in the secure config file. However, this approach is not scalable for us, not only because there will be a significant number of users using this feature and the speed of reading from the config file for each authentication will be directly impacted by the number of users, but also because storing credentials in the secure config file means we would not be able to replicate them across other primary and mirror instances.