[keycloak-dev] Zero-knowledge proof of password?
Marek Posolda
mposolda at redhat.com
Fri Mar 10 05:21:14 EST 2017
On 10/03/17 11:18, Marek Posolda wrote:
> I wonder if it's possible to do the whole handshake in 1 request instead
> of 2 requests, which you would need if you send username in the first
> request.
>
> Something along the lines of:
> - User enters username+password in the browser
> - Browser do some preliminary hashing of the password (eg. hashes it
> with 10K iterations) and send this hash to the server
> - Server will receive the 10K-iterations hashed password and add another
> 10K iterations to it. Then it will compare the final 20K hash with the
> 20K hash from the DB and checks if it match.
>
> This will allow that everything is done in single request, password is
> not sent over the network in cleartext and also there is not the 20K
> hash sent over the network, which won't be good as it will exactly match
> the hash from DB. Not sure if it's doable in practice, just an idea :)
ah, browser doesn't have the password salt, so it won't be able to do
first 10K iterations...
Marek
>
> Marek
>
> On 10/03/17 11:11, Marek Posolda wrote:
>> Kerberos is also similar to this. In fact Kerberos was designed to
>> provide secure communication over insecure network. All the handshakes
>> are done in a way that sender usually encrypts the ticket/sessionKey by
>> some secret known by the receiving party (eg. hash of the user
>> password). And yes, Kerberos also sends defacto just the username in the
>> first request of the username-password verification handshake.
>>
>>
>> Marek
>>
>> On 09/03/17 16:10, Bill Burke wrote:
>>> 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 at lists.jboss.org
>>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
>>>> Sent: Wednesday, March 8, 2017 8:46 PM
>>>> To: keycloak-dev at 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 at 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 at lists.jboss.org
>>>>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
>>>>>> Sent: Tuesday, March 7, 2017 6:06 PM
>>>>>> To: keycloak-dev at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
More information about the keycloak-dev
mailing list