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

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(a)redhat.com&gt; 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(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&gt; > >>>> 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 > >>>> > >>> _______________________________________________ > >>> 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