[ 
https://issues.apache.org/jira/browse/VFS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688933#action_12688933
 ] 

Sergey Vladimirov commented on VFS-169:
---------------------------------------

Joerg,

1) Personally, i completly unlike masking password in exception. It's not the 
place where it should be done. Looks like a hack for me.

There is a lot of other places where passowrd inside of URI should be masked. 
For example - debug output of my own program (FileName.toString() or 
FileObject.toString() calls). They also should be masked.

2) What about API? We already renamed (in SVN) version number to 2.0-SNAPSHOT, 
and, AFAIK, we can't change it back (some commercial projects already using 
snapshots under 2.x numbering)

Anyway, if the question is only saving FileObject clean of additional methods, 
for 1.x version we can introduce getFriendlyURI() method in AbstractFileName 
and not to copy it to FileObject (do it only in 2.x).

> Thrown exception reveals passwords
> ----------------------------------
>
>                 Key: VFS-169
>                 URL: https://issues.apache.org/jira/browse/VFS-169
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>            Reporter: Joerg Schaible
>            Assignee: Joerg Schaible
>             Fix For: 2.0
>
>         Attachments: vfs-pwd.patch
>
>
> If an exception occurs accessing a FileObject on a FileSystem that is 
> addressed with an URL containing user and password the thrown exception 
> contains the password as part of the error message:
> org.apache.commons.vfs.FileSystemException: Could not connect to SFTP server 
> at "sftp://user:[email protected]/";.
> In such a case the URL should be printed as "sftp://user:*[email protected]/";. 
> Same applied to log messages - at least for INFO and higher.
> This is a security risk, since in big companies exceptions and logs are 
> normally collected and archived in monitoring systems and may reveal the 
> password to persons that have normally no authorization to the target system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to