Two Factor Authentication Requiring Email for Secret Keys

Last post 09-01-2020, 2:09 AM by Flipper. 3 replies.
Sort Posts: Previous Next
  • Two Factor Authentication Requiring Email for Secret Keys
    Posted: 07-28-2020, 2:54 AM

    Hi all,

    Been looking at the documentation relating to enabling Two Factor Authentication for accessing the various Commvault interfaces/consoles as found at https://documentation.commvault.com/commvault/v11/article?p=107087.htm

    In reviewing the documentation, it appears that the initial Secret Key required to set-up a user’s PIN generating Tool is sent be email from the Commvault application the first-time a user attempts to log-in after Two Factor Authentication is enabled.

    Apart from options for customizing two email templates (one containing the PIN and Secret Key, and one sending only the PIN), the only other security option is to use TLS or SSL on the Email Server to further secure the email.  However, it is not clear to me whether choosing the PIN only email  template means the Secret Key is not sent via email since the documentation  about “Obtaining a Secret Key for Two Factor Authentication” explicitly says it is sent by email and only email. At https://documentation.commvault.com/commvault/v11/article?p=7960.htm

    Surely sending a persistent two-factor authentication Secret Key by email, encrypted or not, is not an ideal way to implement this capability, especially as this Secret Key appears to be persistent? 

    Hoping the product team is able to look into leveraging a more secure method of providing the Secret Key that doesn’t rely on an email to the user from the Commvault application. Perhaps the Secret Key can be provided via the web console interface with a limited time-frame to enable it be registered with the PIN generating app or as a QR code that can be scanned by one of the PIN generating apps?

    Regards,

    Michael

  • Re: Two Factor Authentication Requiring Email for Secret Keys
    Posted: 07-28-2020, 8:39 AM

    Hi Michael

    Can only agree with you. E-Mail is probably the worst option to send out the Secret Key, transport encrypted or not. If a trojan gets onto your System it can keylog your private password and extract the key from your mails. 

    Unfortunately so far that is the only documented way of getting it. That said there is certainly a Qcommand or other Script/Function that is used internally to get this created and send out.

    Regards,

    Stefan

  • Re: Two Factor Authentication Requiring Email for Secret Keys
    Posted: 07-29-2020, 1:29 AM

    Hi Stefan,

    Thanks for your input.  


    I have logged a ticket with support in the hope that a customization request is created for making this more robust/secure.

    I know there is a documented procedure to regenerate a Secret Key for a user who has lost their Secret Key, but that too seems to default to emailing the re-generated Secret Key after you have deleted the required config file and asked the user to log-in to the console again.

    I do not recall seeing anything relating to the internal Qcommand or Script/Function that generates the Secret key, so I am assuming this information is for internal Commvault support consumption only; and even if I could find the information, I doubt I could leverage it to generate (pre-create) a Secret Key that isn't triggered by a user attempting to log-in for the first-time after two-factor authenitcation is enabled so I can provide it to them by other means. 

    I will update the thread with any news from the support ticket.

    Regards,

    Michael

     

  • Re: Two Factor Authentication Requiring Email for Secret Keys
    Posted: 09-01-2020, 2:09 AM

    For those interested,

    Support have raised CMR 291632 which will hopefully see improvements to the security/robustness of the two-factor-authentication Secret Key distribution process.

    Regards,

    Michael

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy