[jboss-jira] [JBoss JIRA] (ELY-183) Protocols for password changing

[Jan Kalina (JIRA)]

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

Jan Kalina edited comment on ELY-183 at 8/12/15 12:30 PM:
----------------------------------------------------------

Ok, second idea (but not compatible with standard auth mechanism) - based on OTP priciple:
Clients sends server hash with 1000 iterations. Server store this hash. When client want to login, server ask for hash of the same password with 999 iterations. When clients send it, server add 1 iteration to hash from client and compare output with stored hash - both should now be 1000 iterations hash of the same original string (password or user+realm+password).
Bad news: Scram SASL mechanism not allow it :(


was (Author: honza889):
Ok, second idea (but not compatible with standard auth mechanism) - based on OTP priciple:
Clients sends server hash with 1000 iterations. Server store this hash. When client want to login, server ask for hash of the same password with 999 iterations. When clients send it, server add 1 iteration to hash from client and compare output with stored hash - both should now be 1000 iterations hash of the same original string (password or user+realm+password).
Bad news: Scram SASL mechanism not allow it - nobody can add iteration into scram password without original string... :(

> Protocols for password changing
> -------------------------------
>
>                 Key: ELY-183
>                 URL: https://issues.jboss.org/browse/ELY-183
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>             Fix For: 1.0.0.Final
>
>
> Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-)
> A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options.
> Are there any existing protocols to remotely set a password securely?
> Is there anything specific to our current password types we can take advantage of?
> Are there features of any of our SASL mechanisms to apply a second layer of confidentiality?
> Any other options?



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