[jboss-jira] [JBoss JIRA] (ELY-281) Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API

Tue Sep 1 18:17:05 EDT 2015

    [ https://issues.jboss.org/browse/ELY-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104327#comment-13104327 ] 

Farah Juma edited comment on ELY-281 at 9/1/15 6:16 PM:
--------------------------------------------------------

*OTP credential updates*

For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).

*How OTP credential updates are currently handled*

PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case.

https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L716-L720

*Using the credential verification API instead*

An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits):

https://github.com/fjuma/wildfly-elytron/commits/ELY-281

However, there are a couple of issues with this approach:

1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/org/wildfly/security/sasl/otp/OTPSaslServer.java#L199-L202] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets.

2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear how OTP credential verification and updates would be handled in cases like this with this approach.

was (Author: fjuma):
*OTP credential updates*

For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).

*How OTP credential updates are currently handled*

PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case.

https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L716-L720

*Using the credential verification API instead*

An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits):

https://github.com/fjuma/wildfly-elytron/commits/ELY-281

However, there are a couple of issues with this approach:

1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/org/wildfly/security/sasl/otp/OTPSaslServer.java#L199-L202] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets.

2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear yet how OTP credential verification and updates would be handled in cases like this with this approach.

> Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-281
>                 URL: https://issues.jboss.org/browse/ELY-281
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.
> Relevant chat discussion:
> {quote}
> \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
> \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
> \[8:43 AM\] Kabir Khan: That is what I had planned
> \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
> \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
> \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
> \[8:44 AM\] Kabir Khan: the first option is what stood out to me
> \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
> {quote}

--
This message was sent by Atlassian JIRA
(v6.3.15#6346)