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

I think the closest people have come to what you describe are things like FreeOTP or the RSA Firewall fobs. These provide one way passwords that are based on "what you know" and do not require of transmitting a permanent password over cleartext. Hope this helps! On Tue, Mar 7, 2017 at 6:05 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > 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 >

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

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

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

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

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 :)

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

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

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