I think HTTP Digest was written for non-TLS connections and works similarly.
FYI, this also requires the client provide a username prior to
authentication as you need to know the salt, algorithm, and number of
hash iterations that were used to hash the password for that particular
user. To prevent attackers from guessing usernames, the client should
always be provided with this information whether or not the username exists.
I think you could definitely implement something here. Would be a nice
feature for Keycloak.
On 3/9/17 8:14 AM, Peter K. Boucher wrote:
I think if I were going to tweak it myself, I would do something
patterned
after what NTLM did:
Server generates pseudo-random nonce and sends it with the ID of the
hash-algorithm it used when storing the password:
Server ----(hash algorithm, salt, nonce)----> Client
Client hashes password with specified algorithm and salt.
Client generates pseudo-random IV and encrypts the specified nonce, using
the output of the hash as the key, and sends the IV and the encrypted nonce
to the Server:
Client ----(IV, AES block-encrypted nonce with hash as key)----> Server
Server uses stored hash and specified IV to decrypt nonce, and compares
nonce to what was sent to the Client.
This way, the password is never transmitted at all, but this
challenge-response protocol serves to prove that the Client knows the
password.
Anyway, I think my main question was answered that no one has done such a
proof-based protocol with keycloak so far, right?
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org
[mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Bill Burke
Sent: Wednesday, March 8, 2017 8:46 PM
To: keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Zero-knowledge proof of password?
So, you want to create the hash in the browser or proxy, then transmit
this to Keycloak. Keycloak compares the hash to the precalculated hash
it has stored? I don't see how this is any more secure. You're still
passing the credential (the hash) in clear text.
BTW, I think other issues that make things more complex with client
hashing is if
* You need to bump up the number of hashing iterations. (recommended
value changes every 5 years or so)
* Change the hashing algorithm. (SHA-1 was just broken).
On 3/8/17 6:45 PM, Niels Bertram wrote:
> Hi Peter, your security is only ever as good as the weakest link. Given
you transmit the password using SSL up to your VPC why would you need to
"strengthen" (obfuscate rather) the password from there to the keycloak
socket? From what I have seen there are 2 ways to proxy a message, 1) to
tunnel the SSL or 2) reencrypt it in the proxy. Maybe 1) is an option for
you as this setup would not decrypt your message ... although this comes
with other drawbacks. I am intrigued as to what exactly you are trying to
achieve by modifying the messages on the way though a proxy. Any chance you
could elaborate on your security requirement?
>> On 8 Mar. 2017, at 23:33, Peter K. Boucher <pkboucher801(a)gmail.com>
wrote:
>> Sorry, I should have described our scenario more thoroughly.
>>
>> We have one of these at the border of our VPC:
>>
https://en.wikipedia.org/wiki/TLS_termination_proxy
>>
>> We can accept the risk of data being transmitted in the clear inside the
>> VPC, but we would prefer that passwords not be transmitted in the clear.
>>
>> It's an old problem. NTLM also used a proof of the password rather than
>> transmitting the password for similar reasons.
>>
>> We could force that TLS be used inside the VPC between the TLS
termination
>> proxy and Keycloak, but even then, the passwords are decrypted and then
>> re-encrypted.
>>
>> We are considering trying to use something like the client-side hashing
>> described here:
https://github.com/dxa4481/clientHashing
>>
>> The question for this group was related to whether anyone has already
>> developed anything along these lines for use with Keycloak.
>>
>> Thanks!
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces(a)lists.jboss.org
>> [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Bill Burke
>> Sent: Tuesday, March 7, 2017 6:06 PM
>> To: keycloak-dev(a)lists.jboss.org
>> Subject: Re: [keycloak-dev] Zero-knowledge proof of password?
>>
>> What does that even mean? Keycloak's SSL mode can forbid non SSL
>> connections. FYI, OIDC requires SSL.
>>
>>
>>> On 3/7/17 4:22 PM, Peter K. Boucher wrote:
>>> Suppose you don't want your passwords transmitted in the clear after SSL
>> is
>>> terminated by a proxy.
>>>
>>>
>>>
>>> Has anyone developed a secure way for the client to prove they have the
>>> password, rather than transmitting it in the body of a post?
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev