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

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(a)gmail.com&gt; 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(a)redhat.com&gt; > 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(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 >> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev