[ 
https://issues.apache.org/jira/browse/FTPSERVER-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446158#comment-16446158
 ] 

Jonathan Valliere commented on FTPSERVER-485:
---------------------------------------------

Unless I misunderstood the purpose of this bug report, I thought the goal was 
to prevent the time to compare from leaking characteristics about the valid 
password?  In my solution, the performance penalty only comes into play when 
the passwords don't match.  Even then, the performance penalty is probably in 
the order of micro secs.  It could be made more secure by purposely wasting 
cycles using a random value based on the input length, but that would be 
overkill.

I'm open to alternatives which give the same level of timing protection.  
Otherwise I'll add the unit tests and push the patch sometime this weekend.  
I'm also probably going to add a global fixed password length to prevent input 
password flooding if one does not exist.

> Timing Side Channel PasswordEncryptor
> -------------------------------------
>
>                 Key: FTPSERVER-485
>                 URL: https://issues.apache.org/jira/browse/FTPSERVER-485
>             Project: FtpServer
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.1
>         Environment: tested on macOS High Sierra 10.13.4, but it is not 
> relevant
>            Reporter: Yannic Noller
>            Assignee: Jonathan Valliere
>            Priority: Major
>              Labels: easyfix, pull-request-available
>             Fix For: 1.1.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Dear Apache FTPServer developers,
> We have found a timing side-channel in class 
> org.apache.ftpserver.usermanager.ClearTextPasswordEncryptor, method "public 
> boolean matches(String passwordToCheck, String storedPassword)". This is due 
> to the use of String.equals for comparison which returns as soon as a 
> character does not match. This represents a timing side channel, which could 
> be used by a potential attacker to obtain knowledge about the hidden secret 
> password.
> Do you agree with our findings?
> A similar issue is present in method "matches" from classes 
> org.apache.ftpserver.usermanager.Md5PasswordEncryptor and 
> org.apache.ftpserver.usermanager.SaltedPasswordEncryptor.
> We found these classes in the latest version of your git repo: 
> https://git-wip-us.apache.org/repos/asf?p=mina-ftpserver.git;a=summary
> The problem can be fixed easily by using the following safe version for 
> String comparison in all three methods:
> public boolean isEqual_safe(String a, String b) {
>         char a_value[] = a.toCharArray();
>         char b_value[] = b.toCharArray();
>         boolean unused;
>         boolean matches = true;
>         for (int i = 0; i < a_value.length; i++) {
>             if (i < b_value.length) {
>                 if (a_value[i] != b_value[i]) {
>                     matches = false;
>                 } else {
>                     unused = true;
>                 }
>             } else {
>                 unused = false;
>                 unused = true;
>             }
>         }
>         return matches;
>  }
> Do you agree with our patch proposal?
> Please feel free to contact us for further clarification! You can reach us by 
> the following email address:
> [email protected]
> Best regards,
> Yannic Noller



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to