You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should support generating a new SCRAM credential to replace an existing one, replacing the password, hash, etc. but keeping the same permissions (and probably name). We currently support suspending credentials which are suspected to be compromised, allowing them to be examined without destroying their permission information, but we currently can only un-suspend a credential (if the security team decides it is in fact not a concern) or delete it. Allowing the user to regenerate it should be another option. (Regeneration of a suspended credential should perhaps not immediately remove the suspension status, in case of compromised SSO credentials, however.)
A possible concern is that an attacker who has a valid user's SSO credentials could regenerate a SCRAM credential, disabling the legitimate user's use of the old value, and enabling the attacker to use the new value. However, this does not seem to add much to the way that such an attacker could already delete an existing credential, and generate a new one. The credential name would not be the same, and permissions would have to be manually re-added, but there seems to be little qualitative difference.
The text was updated successfully, but these errors were encountered:
Following a suggestion by Alex Pace:
We should support generating a new SCRAM credential to replace an existing one, replacing the password, hash, etc. but keeping the same permissions (and probably name). We currently support suspending credentials which are suspected to be compromised, allowing them to be examined without destroying their permission information, but we currently can only un-suspend a credential (if the security team decides it is in fact not a concern) or delete it. Allowing the user to regenerate it should be another option. (Regeneration of a suspended credential should perhaps not immediately remove the suspension status, in case of compromised SSO credentials, however.)
A possible concern is that an attacker who has a valid user's SSO credentials could regenerate a SCRAM credential, disabling the legitimate user's use of the old value, and enabling the attacker to use the new value. However, this does not seem to add much to the way that such an attacker could already delete an existing credential, and generate a new one. The credential name would not be the same, and permissions would have to be manually re-added, but there seems to be little qualitative difference.
The text was updated successfully, but these errors were encountered: