[RTFACT-17038] Encrypted password from local user changes unexpectedly Created: 28/Jun/18  Updated: 07/Apr/20

Status: Open
Project: Artifactory Binary Repository
Component/s: None
Affects Version/s: 5.10.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Sander Wartenberg Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: QF, QF-P2


 Description   

Hi guys,

Since we upgraded to Artifactory 5.10.1 we noticed that the encrypted password of our (only) local user changes from time to time while the plain password does not. Of course we are happy the plain password does not change but as a result of the unexpected change, our maven settings on our CI's for example do not work anymore.

A workaround for now is to update the maven settings.

 



 Comments   
Comment by Vincent Jansen [ 16/Jul/18 ]

Today this happened again, we upgraded to 6.1.0 in the begin of july, but the hash has changed again last night. Is there something i can search for in the logs?

Comment by Vincent Jansen [ 16/Jul/18 ]

In the log I see the following line, could this be related?

2018-07-16 08:19:16,266 [http-nio-8080-exec-772] [INFO ] (o.a.s.SecurityServiceImpl:1539) - Creating keys for user 'ci-ef'
Comment by Vincent Jansen [ 16/Jul/18 ]
2018-07-16 08:19:16,266 [http-nio-8080-exec-772] [INFO ] (o.a.s.SecurityServiceImpl:1539) - Creating keys for user 'ci-ef'
2018-07-16 08:19:39,513 [http-nio-8080-exec-771] [WARN ] (o.a.s.PasswordDecryptingManager:143) - Failed decrypting password. Trying to authenticate with original password.
2018-07-16 08:20:52,853 [http-nio-8080-exec-785] [INFO ] (o.a.a.s.CrowdHttpAuthenticator:200) - Logging out crowd user without a valid token
2018-07-16 08:24:46,758 [art-exec-8] [INFO ] (o.a.a.r.b.c.ReleaseBundleCleanupServiceImpl:82) - Starting to cleanup incomplete Release Bundles
2018-07-16 08:24:46,773 [art-exec-8] [INFO ] (o.a.a.r.b.c.ReleaseBundleCleanupServiceImpl:88) - Finished incomplete Release Bundles cleanup
Comment by Vincent Jansen [ 01/Aug/18 ]

This seems to happen multiple times a month, these are the last 3 times it happend (could be the day before, but we changed the maven hash on the following days):

  • 2018-07-30
  • 2018-07-16
  • 2018-06-28
     
Comment by Vincent Jansen [ 01/Aug/18 ]

We are running Artifactory Pro (now 6.1.0 as we try to keep it up-to-date) on CentOS 7.5

Comment by Vincent Jansen [ 13/Aug/18 ]

It happened again, because of the characteristics of maven we noticed first builds failing on 2018-08-11 12:40.
Which logfile(s) should I save?

Comment by Vincent Jansen [ 13/Aug/18 ]

We are looking through the source code of the open source code (of 6.1.0). Based on the logging I get the following seems to be true:

if (StringUtils.isBlank(user.getPrivateKey())) { 

I would expect that this would only be true until the first time the user uses the username/password combination, is there an other situation where the privateKey could be blank?

We use authentication via crowd and with internal users (the user in scope is an internal user).

Comment by Vincent Jansen [ 20/Aug/18 ]

Lets see if the next time the encrypted password changes if the private and public keys change as well.
We will store these ones to check them next time it occurs. I have put them in our internal keepass repository.

Also, from which version have you upgraded.
5.0.1 (2017-02-XX) -> 5.4.6 (2017-08-18) -> 5.10.1 (2018-04-11) -> 6.1.0 (2018-07-04)

In addition, how frequently the encrypted password change?
Days we detected it (could have occurred earlier)

  • 2018-06-28
  • 2018-07-16
  • 2018-07-30
  • 2018-08-08
  • 2018-08-13 (weekend before that)
  • 2018-08-13 (during the day)
Comment by Vincent Jansen [ 31/Aug/18 ]

Today it happened again. I checked the public and private keys and multiple internal users (which I know haven't changed their password) have a changed private and public key, but there are that have the same private and public key as before. The only thing I can tell is that the users I checked that have the same private and public key are users we do not use often to log in and the users that have a changed private and public key we use to log in to the webapplication sometimes to check stuff.

One is the admin user and the other one is a normal user (which we use internally and uses the maven has to do checkouts).

Comment by Darren Nolan [ 24/Oct/18 ]

Jumping on the thread to get notices about this.

We're facing this issue at work, causing massive issues in our CI/CD pipelines at least once a month.

Comment by Tudor Dumitrescu [ 06/Nov/18 ]

Hi, 

It's happening to our Artifactory Pro v6.0.3.

I noticed that : 

  • It only happens to our NPM user, we separated the users in order to debug the problem, so maven has it's own user, npm has another user...etc.
  • It appear to happen once a month.
  • The hash changes but the password is the same.
  • We get a series of warning in our log every time this happens (see callstack below).

 

2018-11-02 17:49:03,660 [ajp-nio-8019-exec-69] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,660 [ajp-nio-8019-exec-82] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,661 [ajp-nio-8019-exec-78] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,669 [ajp-nio-8019-exec-76] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,669 [ajp-nio-8019-exec-94] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,669 [ajp-nio-8019-exec-73] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,675 [ajp-nio-8019-exec-79] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,675 [ajp-nio-8019-exec-91] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,677 [ajp-nio-8019-exec-87] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:03,677 [ajp-nio-8019-exec-90] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:49:08,446 [ajp-nio-8019-exec-94] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:50:10,034 [ajp-nio-8019-exec-91] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:56:32,205 [ajp-nio-8019-exec-73] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:59:37,998 [ajp-nio-8019-exec-78] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:59:37,999 [ajp-nio-8019-exec-87] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:59:37,998 [ajp-nio-8019-exec-73] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:59:38,002 [ajp-nio-8019-exec-82] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.
2018-11-02 17:59:38,002 [ajp-nio-8019-exec-94] [WARN ] (o.a.s.PasswordDecryptingManager:135) - Failed decrypting password. Trying to authenticate with original password.

Thanks. 

Comment by Vincent Jansen [ 15/May/19 ]

We have replaced the user with a new one (first replaced the user with a group for easy replacement) and so far the problem has not occurred this year .

Comment by Marek Wasilewski [ 20/May/19 ]

Any news on this issue?

Comment by Marek Wasilewski [ 21/May/19 ]

i've got a feeling that this bug breaks connection between artifactory and xray in our instance.

Comment by Serge Simonov [ 25/Oct/19 ]

Jfrog colleagues - do you have an update? When are you planning to work on this issue? 

Generated at Wed Apr 08 10:23:37 UTC 2020 using Jira 8.5.3#805003-sha1:b4933e02eaff29a49114274fe59e1f99d9d963d7.