Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Talk about PAKE (2018)

blog.cryptographyengineering.com

Post reply on HN
Print view View original

11–20 of 70 posts

Re: Let’s Talk about PAKE (2018)

#11

Post by tptacek »

bastawhiz wrote: post #8

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…

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

Re: Let’s Talk about PAKE (2018)

#12

Post by nly »

tptacek wrote: post #11
bastawhiz wrote: post #8

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…

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

Indeed. It's hard to come up with use cases where a chosen, long-term low entropy secret is more suitable than alternatives like:

1) Factory paired devices

2) Pairing via ephemeral key pairs with out-of-band verification of a low entropy hash/fingerprint to prevent active MITM.

3) Straight up TOFU (trust on first use) pairing (and just praying MITM doesn't happen on first use).

The only case comes to mind is one where one device, although still physically trusted, has no persistent memory at all (and so can't store any keys).

Re: Let’s Talk about PAKE (2018)

#13

Post by GoblinSlayer »

bastawhiz wrote: post #8

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…

There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.

Re: Let’s Talk about PAKE (2018)

#14

Post by GoblinSlayer »

tptacek wrote: post #11
bastawhiz wrote: post #8

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…

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

A mentioned use case is twitter logging requests on server side.

Re: Let’s Talk about PAKE (2018)

#16

Post by br1 »

GoblinSlayer wrote: post #14
tptacek wrote: post #11

Earlier quoted context omitted.

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

A mentioned use case is twitter logging requests on server side.

Exactly, it's to protect your user from you.

Re: Let’s Talk about PAKE (2018)

#17

Post by amluto »

tptacek wrote: post #11
bastawhiz wrote: post #8

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…

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

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.

Re: Let’s Talk about PAKE (2018)

#18

Post by bastawhiz »

GoblinSlayer wrote: post #13
bastawhiz wrote: post #8

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…

There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.

Even if it's conceptually simpler, it still suffers from the same issues in my comment

Re: Let’s Talk about PAKE (2018)

#19

Post by boardwaalk »

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.

Re: Let’s Talk about PAKE (2018)

#20

Post by baby »

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

Post reply on HN