You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Vaishnavi Kumbhar (Jira)" <ji...@apache.org> on 2026/03/02 10:52:00 UTC
[jira] [Updated] (VFS-861) Http5FileProvider Basic authentication fails: password in credentials is wiped by UserAuthenticatorUtils.cleanup(authData)
[ https://issues.apache.org/jira/browse/VFS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vaishnavi Kumbhar updated VFS-861:
----------------------------------
Description:
We discovered authentication problem when migrating our application from deprecated Http4FileProvider to Http5FileProvider.
*Our analysis of the problem:* In {{{}Http5FileProvider.createHttpClientContext(){}}}, the password is passed to {{UsernamePasswordCredentials}} as the *same {{char[]}}* reference returned from {{{}UserAuthenticatorUtils.getData(authData, PASSWORD, ...){}}}. In {{{}doCreateFileSystem(){}}}, {{UserAuthenticatorUtils.cleanup(authData)}} is called in a {{finally}} block to clear sensitive data. That method zeros the character arrays inside {{{}authData{}}}. Because the credentials object holds a *reference* to the same array, the password in the credentials is also zeroed *before* any HTTP request is made. Http4 does not have this bug because it uses {{{}UserAuthenticatorUtils.toString(getData(...)){}}}, which creates a *new String* (a copy), so the credentials keep their own data.
h2. Reproduction project
[https://github.com/VaishKumbhar/vfs2-issue]
Clone and run {{mvn test}} to reproduce.
was:
We discovered authentication problem when migrating our application from deprecated Http4FileProvider to Http5FileProvider.
*Our analysis of the problem:* In {{{}Http5FileProvider.createHttpClientContext(){}}}, the password is passed to {{UsernamePasswordCredentials}} as the *same {{char[]}}* reference returned from {{{}UserAuthenticatorUtils.getData(authData, PASSWORD, ...){}}}. In {{{}doCreateFileSystem(){}}}, {{UserAuthenticatorUtils.cleanup(authData)}} is called in a {{finally}} block to clear sensitive data. That method zeros the character arrays inside {{{}authData{}}}. Because the credentials object holds a *reference* to the same array, the password in the credentials is also zeroed *before* any HTTP request is made. Http4 does not have this bug because it uses {{{}UserAuthenticatorUtils.toString(getData(...)){}}}, which creates a *new String* (a copy), so the credentials keep their own data.
h2. Reproduction project
[|https://github.com/VaishKumbhar/vfs2-issue#reproduction-project]
[https://github.com/VaishKumbhar/vfs2-issue]
Clone and run {{mvn test}} to reproduce.
> Http5FileProvider Basic authentication fails: password in credentials is wiped by UserAuthenticatorUtils.cleanup(authData)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: VFS-861
> URL: https://issues.apache.org/jira/browse/VFS-861
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Vaishnavi Kumbhar
> Priority: Major
>
> We discovered authentication problem when migrating our application from deprecated Http4FileProvider to Http5FileProvider.
> *Our analysis of the problem:* In {{{}Http5FileProvider.createHttpClientContext(){}}}, the password is passed to {{UsernamePasswordCredentials}} as the *same {{char[]}}* reference returned from {{{}UserAuthenticatorUtils.getData(authData, PASSWORD, ...){}}}. In {{{}doCreateFileSystem(){}}}, {{UserAuthenticatorUtils.cleanup(authData)}} is called in a {{finally}} block to clear sensitive data. That method zeros the character arrays inside {{{}authData{}}}. Because the credentials object holds a *reference* to the same array, the password in the credentials is also zeroed *before* any HTTP request is made. Http4 does not have this bug because it uses {{{}UserAuthenticatorUtils.toString(getData(...)){}}}, which creates a *new String* (a copy), so the credentials keep their own data.
> h2. Reproduction project
> [https://github.com/VaishKumbhar/vfs2-issue]
> Clone and run {{mvn test}} to reproduce.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)