[keycloak-dev] Zero-knowledge proof of password?

Marc Savy marc.savy at redhat.com
Mon Mar 13 07:09:07 EDT 2017 

This sounds like a candidate for HTTP Signatures - i.e. strictly a
verifiability and integrity issue rather than confidentiality. The
likes of Amazon use this approach AIUI.

See: https://github.com/tomitribe/http-signatures-java

This would enable you to continue with TLS termination but retain
verifiability, non-repudiation, etc for interested parties.

The downside, of course, is that the involved parties need to have
keys to perform the verification - however, it's non-invasive in that
it doesn't break anything for disinterested parties.

NB: I'm not claiming that KC should be doing this - perhaps it should
be capable of it, but I think that's still open for discussion.

On 10 March 2017 at 10:42, Stian Thorgersen <sthorger at redhat.com> wrote:
> If you're talking about some non-web based client it would still need to
> use SSL as otherwise tokens are still sent in clear text and can be
> exploited. So I don't see the use-case for it there either.
>
> On 10 March 2017 at 11:39, Niels Bertram <nielsbne at gmail.com> wrote:
>
>> For a normal webpage or app I can't see it either. But there might be some
>> use for it when you want to do authentication from pin pad devices or like
>> where you cannot guarantee what will be between the input device and the
>> auth terminal. But even then you are limited by getting the iterations,
>> salt etc securily to the terminal.
>>
>> On Fri, Mar 10, 2017 at 8:32 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I really don't see the need for this when both OIDC and SAML will require
>>> secure networks in either case.
>>>
>>> On 10 March 2017 at 11:21, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>> > 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
>>> >
>>> >
>>> > _______________________________________________
>>> > 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