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

Fri Mar 10 05:42:30 EST 2017

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