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

Fri Mar 10 12:56:35 EST 2017

again, this is a growing concern. See:
https://en.wikipedia.org/wiki/TLS_termination_proxy. There are many
situations where producer and consumer of some data do not have control
over the SSL-termination. We will definitively have to work on solutions
for encrypting or hashing some critical form fields before sending them
over to the consuming server.

Francis Pouatcha
Open https://github.com/adorsys

On Fri, Mar 10, 2017 at 11:42 AM, 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
>