Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1832426.1173601989439.JavaMail.jira@brutus>
Date: Sun, 11 Mar 2007 00:33:09 -0800 (PST)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Resolved: (DIRSERVER-868) SimpleAuthenticator contains many
 potential pbs
In-Reply-To: <31172148.1173375624279.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DIRSERVER-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny resolved DIRSERVER-868.
-----------------------------------------

    Resolution: Fixed

All the issues are now fixed.

> SimpleAuthenticator contains many potential pbs
> -----------------------------------------------
>
>                 Key: DIRSERVER-868
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-868
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.1, 1.5.0
>            Reporter: Emmanuel Lecharny
>         Assigned To: Emmanuel Lecharny
>             Fix For: 1.5.0
>
>
> While analysing the Authenticator classes, I found that the SimpleAutheticator won't deal correctly with many potential cases :
> - The credentials stored in the java.naming.security.credentials may be a byte array, so transfming it to a String may simply fail
> - as we use a WeakHashMap to store some cached passwords, it would be good to check that the passward has correctly been got from the cache, not that the password exists in the cache then try to get it. We may have a null password in this case.
> - it may be possible that the user hasn't created a password. In this case, we will get an Authentication error because the password won't be found on the server, and the code is expecting to get something.
> - if the password is encrypted, it must be stored as a base 64 encoded String into the server, prefixed with the encryption mechanism. This is OK, but then we can compare passwords using a String comparizon, not a Arrays.equals() on byte arrays, as both elements are Strings.
> I might have missed some steps, or be wrong, so consider this JIRA as a reminder for the real issues.

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