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

Fri Mar 10 05:32:51 EST 2017

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
>