Skip to main content

I was busy writing some code last week and while I was coding the authentication part I noticed the following. When you perform an authentication attempt against the API you will get output information back which contains information that can be used to perform a brute-force attack.

Return information after an invalid authentication attempt:

Now in case you use a valid username than you will see the Loginattempts incrementing:

This means you found a valid account, so let's push forward until it the account is locked!

So the API is also giving back the time you have to wait until you can try it again. 

Exposing this kind of information makes it easier for people with bad intentions to perform brute-force attacks. Sure companies nowadays should embrace/use MFA, but when you want to automate certain actions, for example through a CI/CD pipeline, than the MFA becomes a blocker so you'll have to diverge back. I think it's time to come-up with something better that can be used for automation tasks like for example a true service account blueprint that is allowed to logon through the API alone and uses oauth refresh tokens. For the short term not exposing this information would already be a first step. 

And yes, I know Commvault is showing something in the eventviewer, but this will be visible only in the CommCell console as by default is is part of the default UI layout. In Command Center you really have to have it open which doesn't happen that often hence I would like a different UI layout for Command Center. 

Curious to hear the opinion of others on this!

I totally agree with you on this one @Onno van den Berg.

Going to flag with a few folks.


@Damian Andre shall I open a ticket for it as well?


@Damian Andre shall I open a ticket for it as well?

Hey Onno,

No need - engineering are already actioning this. They are looking at how this impacts the API, Powershell and other interface. 


Ok. One thing I was thinking of is an idea that I had to increment the lockout period upon consecutive failed login attempts. So for example:

First lockout period = 5 min.
Second lockout period = 10 min.
Third lockout period = 20 min.
Permanent lock enabled

But again exposing information that leads to discovering a valid user account is of course not so nice as it attracts people with bad intentions to at least give it a try.


Quick update here. Tracking change to remove this info from the API - Form 165300

 


Thanks for the update @Damian Andre


@Onno van den Berg , I just checked the form ID.  Looks like 11.32 is the pending release.


@Onno van den Berg , I just checked the form ID.  Looks like 11.32 is the pending release.

Just to add, fixed or enhancements always get created on the current open branch and when done it can be back ported to other releases. So it will most certainly be released for prior FRs


Thanks for the update @Damian Andre! Much appreciated! 


I cannot find this item in the release notes for 11.32


No, unfortunately these kind of backported enhancements are not documented. So, the only way to find out is to check it out or for someone from CVLT to respond to this post which maintenance release contains the enhancement. 


Reply