jim at manico.net
Thu Jan 3 15:04:20 EST 2008
Thanks for responding. I was thinking more along the lines of
multi-factor authentication - or at least the additional steps in the
auth process that we are seeing in the banking industry.
For all of my banking accounts, I am now being asked to enter in or
select several questions (what is your mothers maiden name, what is the
name of your first girlfriend, etc) as well as verify a specific
pre-selected image for phishing protection as part of the auth process.
I see this at Wellsfargo, Countrywide, and my local Hawaii bank. And
this is not for password retrieval, it's part of the auth process.
Forgive me if I'm not using the proper industry-standard terms for these
So I'm thinking along the lines of
IUser createUser(String accountName, String password1, String password2, Map questionAnswerMap, int phishingImage) throws AuthenticationException;
Seemed to be a somewhat standard security approach (at least in finance)
since we have seen it across so many popular $ sites.
On the subject of createUser accepting a plaintext password, perhaps
augmenting the interface Javadoc as such?
* Creates the user. *Implementors of this interface should be sure
to use best-practice to hash the password before persisting.
* @param accountName
* the account name
* @param password1
* t*he plaintext password*
* @param password2
* *copy of the plaintext password*
* @return the new User object
* @throws AuthenticationException
* the authentication exception
IUser createUser(String accountName, String *plaintextPassword1*,
String *plaintextPassword2*) throws AuthenticationException;
> Hi Jim,
>> We could add
>> IUser createUser(String accountName, String password1, String password2,
>> Map questionAnswerMap) throws AuthenticationException;
> I think we should do something to support forgotten passwords, but I'm not
> sure the secret question approach is very good. I guess in the absence of a
> clear best approach, I had planned to let people innovate their own
> solutions. But providing support for this is something we should consider.
> Anyone feel strongly about this?
>> On a similar note - I assume you expect the caller of createUser
>> function to hash the password before hitting it. Perhaps with a little
>> inheritance we could force that - or at least add a little Javadoc at
> Actually, the createUser() method does expect plaintext - basically exactly
> what you'd get from the change password form (username, password1,
> password2). This calls the User() constructor, which does the hashing
> automatically. I'd rather not rely on developers to do this hashing
VP Software Engineering, Codemagi Inc.
Application Security Instructor, Aspect Security
jim at codemagi.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-ESAPI