[HN Gopher] Let's Talk about PAKE
___________________________________________________________________
Let's Talk about PAKE
Author : ctoth
Score : 37 points
Date : 2021-10-21 19:53 UTC (3 hours ago)
(HTM) web link (blog.cryptographyengineering.com)
(TXT) w3m dump (blog.cryptographyengineering.com)
| boardwaalk wrote:
| Fun fact: World of Warcraft used SRP4 for a long while (I'm not
| sure if it does anymore). That's a pretty big deployment.
|
| But this article will be useful; I have something unreleased that
| does password authentication by dumping the salt to the user,
| just out of ease of implementation. I'll probably take another
| look at it.
| tptacek wrote:
| Relatedly, a recent post on SRP (the most commonly used PAKE) and
| how it's worse in all cases than PAKEs derived from SPEKE:
|
| https://tobtu.com/blog/2021/10/srp-is-now-deprecated/
| ignoramous wrote:
| Curious to know your thoughts on: "...what are [some] problems
| [tptacek has] with password-authenticated key exchange?"
|
| https://news.ycombinator.com/item?id=18260407
|
| Thanks.
| georgelyon wrote:
| There's some dust on it, but I made a proof-of-concept OPAQUE
| implementation some years back (disclaimer: this was done for
| educational, not security, purposes). The README has some good
| discussion of the various components of OPAQUE, and I'd argue the
| code (mostly C) is quite readable. If folks are interested, I'd
| encourage them to take a look:
| https://github.com/GeorgeLyon/Opaque.
| makeworld wrote:
| Library for PAKE (but not OPAQUE specifically) in Go:
| https://github.com/schollz/pake
| kodablah wrote:
| A few years ago, I saw this article and wrote
| https://github.com/cretz/gopaque as a learning exercise (meaning
| I am no cryptographer, code has not been vetted, probably
| outdated, etc). See
| https://pkg.go.dev/github.com/cretz/gopaque/gopaque for docs on
| how it abstracts registration and authentication.
| nly wrote:
| Frank Denis has an elliptic curve PAKE built on top of libsodium
| called CPACE. The implementation is less than 150 lines of C
|
| https://github.com/jedisct1/cpace
| baby wrote:
| shameless plug: I wrote some ELI5 explanations on some of these
| technologies:
|
| - SRP: https://www.cryptologie.net/article/503/user-
| authentication-...
|
| - SPAKE2: https://www.cryptologie.net/article/490/whats-a-
| symmetric-pa...
|
| - OPAQUE: https://livebook.manning.com/book/real-world-
| cryptography/ch...
|
| - CPACE: https://livebook.manning.com/book/real-world-
| cryptography/ch...
| mellosouls wrote:
| (2018)
| collegeburner wrote:
| Why did he recommend OPAQUE over others like SPAKE2?
|
| Re: Green's question on why it is not more widely deployed, I
| assume it is since TLS already is common and PAKE would be an
| additional layer of encryption on this? Or is his proposal use
| PAKE for auth then discard keys, use TLS normally?
| RcouF1uZ4gsC wrote:
| One of the reasons I love reading about crypto algorithms is that
| there is a certain elegance and the pleasure of solving an
| intellectual puzzle when you read them.
|
| I felt this way when I first read about RSA and public key
| encryption, and Shamir's secret sharing algorithm
|
| This article gave me the same feeling with regards to OPAQUE.
|
| I don't know that I will ever personally implement the algorithm,
| but just knowing about it is gives me a certain nerdy pleasure.
|
| Thanks for the great writeup.
| sedatk wrote:
| So, OPAQUE stands for what? Or, do we not care anymore? :)
| Apparently, it's based on "aPAKE" which stands for "Asymmetric
| PAKE", but I guess OPAQUE is an acronym that sounds cool.
| bastawhiz wrote:
| I probably would never try to implement this on my own website.
| My login pages don't use JS, so unless the browser did the work
| for me, it's complexity that I'm never going to understand
| running on the most crucial page on my site.
|
| Moreover, though, users run _so much shit_ in their browsers.
| More than half of the logged errors on my site are from user
| scripts and browser extension content scripts doing lord knows
| what. They can all just slurp the value out of the DOM, no
| questions asked. Never mind my CSP, HTTPS, and all of the effort
| I go to making my server environment secure and safe. The weakest
| link is not the password getting sent to my servers (over HTTPS),
| it 's the utter free-for-all happening on the page in the first
| place.
| tptacek wrote:
| It's really hard to come up with a sane reason why you would
| ever implement a PAKE with a browser HTTPS application.
| Probably the best-known use of any PAKE is in Magic Wormhole,
| where the PAKE passphrase (auto-generated) is a fundamental
| part of the trust model, and the application itself never
| touches a browser.
|
| It's a problem with PAKEs that they're kind of neat to think
| about and play with, so people look for things to stick them
| onto. They're usually not the answer, which is why you don't
| see them used all that often, and why they're used almost
| exclusively in custom protocol settings.
|
| (It doesn't help PAKE adoption that most custom protocols are
| better served by standard authenticated key exchanges based on
| real cryptographic secrets, rather than passphrases).
| GoblinSlayer wrote:
| A mentioned use case is twitter logging requests on server
| side.
| br1 wrote:
| Exactly, it's to protect your user from you.
| nly wrote:
| Indeed. It's hard to come up with use cases where a chosen,
| long-term low entropy secret is better than straight up
| Diffie-Hellman with emphemeral key pairs and out-of-band
| verification of a low entropy hash.
|
| One thing that comes to mind is where one endpoint device
| doesn't have a screen. Another might be in cases where TOFU
| just isn't good enough (MITM risk) and you can't update a
| certificate (no internet connectivity) or a trusted
| certificate store.
|
| But yeah, it's very niche. Some combination of out of band
| pairing and TOFU seems to cover most use cases.
| amluto wrote:
| If we could go back in time and teach users that passwords
| are _only_ to be entered into browser chrome, and if that
| used PAKE, we would be in pretty good shape.
| nly wrote:
| HTTP Basic Authentication was a thing in the 90s. Couple
| that with TLS+PFS and you already have all the benefits of
| PAKE, plus the more useful benefit of having a third party
| verify the identify of the web server the first time you
| visit.
|
| The major reason HTTP Auth failed, despite the primitive
| crypto, is the bad client side UX.
| GoblinSlayer wrote:
| There's a simpler protocol SCRAM based on just a hash function
| and similarly doesn't send a cleartext password.
| bastawhiz wrote:
| Even if it's conceptually simpler, it still suffers from the
| same issues in my comment
| GoblinSlayer wrote:
| If you mean login without javascript, that can't be helped.
| If you mean password slurped from DOM, you can't possibly
| make it worse.
___________________________________________________________________
(page generated 2021-10-21 23:00 UTC)