[ https://issues.apache.org/jira/browse/FTPSERVER-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445946#comment-16445946 ]
Jonathan Valliere edited comment on FTPSERVER-485 at 4/20/18 4:09 PM: ---------------------------------------------------------------------- [~elecharny] that is exactly what I was going to do; force comparison against every character in the source; forcing additional loops in the for-loop when positions don't exist in the target. was (Author: johnnyv): [~elecharny] that is exactly what I was going to do; force comparison against every character before returning true or false up to the length of the source or target whichever is less. > 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: > yannic.nol...@informatik.hu-berlin.de > Best regards, > Yannic Noller -- This message was sent by Atlassian JIRA (v7.6.3#76005)