[jboss-jira] [JBoss JIRA] (ELY-183) Protocols for password changing
[
https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy...
]
Jan Kalina edited comment on ELY-183 at 8/12/15 10:49 AM:
----------------------------------------------------------
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... :(
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 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)