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

41–50 of 70 posts

Re: Let’s Talk about PAKE (2018)

#41

Post by gdavisson »

nly wrote: post #25
jimktrains2 wrote: post #24

Earlier quoted context omitted.

Not _all_ the benefits. PAKE doesn't share the password with thr server. I would argue the reason http auth failed is that there is no means of logging out, part of that is ui, part of that is protocol.

> PAKE doesn't share the password with thr server. The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline. I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.

A server may store the password hashed, but in a password-over-TLS flow the password is received by the server in plaintext. It is only encrypted on the wire (& the network stack).

Look at all the places in a standard authentication flow where the plaintext password is exposed:

- Any TLS-stripping middleboxes on the client's network. (My personal security nightmare is that someone finds a vulnerability in one of those, and hacks them to scrape anything that looks like a password.) BTW, remember when Kazakhstan did this to their entire country?

- Any TLS-terminating load balancer/front-end-server/etc at the server side of the network.

- Potentially between the front-end server and a backend that does the actual authentication, depending on how traffic is passed there.

- Finally, the server that's doing the authentication -- the password will at the very least be exposed in memory there, so anyone who can read its memory (or modify the server code to leak the passwords) can collect passwords in plaintext.

Re: Let’s Talk about PAKE (2018)

#42

Post by xyzzy123 »

cvwright wrote: post #29
tptacek wrote: post #28

Earlier quoted context omitted.

I don't understand why you would ever protect an encrypted archive of keys stored serverside with a passphrase authenticated from a password hash stored on the server (which is effectively how a PAKE works). It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. (SRP is pretty much dead now, for what it's worth).

Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is laz…

I think you might as well client-side hash it under these circumstances?

Like the "proper" answer is rethink your protocol, have 1 password and make everything not suck.

Minimum (and achievable) job? Client side hash.

Yes it's sh%tty JS crypto in the web case but you have legacy reasons you don't want plaintext even over SSL and you're not going to promise "military grade crypto" to anyone. It's explicable. You can use existing decently reviewed JS libs at least. Any kind of PAKE was gonna be weird JS libraries for web folks anyway.

Yes you're exposed to all the CDNs your UIs use but you were exposed to them anyway.

OK yes tptacek JS crypto is bad and the browser is the worst runtime ever but it's still orders of magnitude less code than needed to make a functional web ui for a chat client, it's pretty bounded, testable and the worst case screwup is not much different than sending your password to the server in plaintext. Which is current state.

The server can store a sha256 of the PBKDF2 output of your client hashing process or whatevs? It's likely to be harder to crack than the key blob you stored on servers already. From a data at rest and in flight standpoint this is at least the same security you get from a PAKE but way easier for everyone to understand. It's one-round, no one needs to think, on server side you can still politely upgrade with zero user interaction. Clients don't have to use fringe crypto supported by one person on github. (Good luck finding a cocoa pod for any kind of PAKE).

It will get weird sending salts to clients if you care about username enumeration, feels like the only way for that not to be stateful in a bad way on your servers is if you derive it from email or login id or something (aka don't actually need to store or send). Not sure how you would resolve that if your UX needs to support multiple login identifiers. That would be hard because you have secret but pre-auth information (relationship between names), and it would require its own sort of thinking.

I have zero knowledge of matrix and so this will probably go down as an embarassing comment. The things I don't know here outweigh the things I do, so this is probably bad advice.

I do want to say, sometimes you just have to go low tech and the dumb thing is the best answer. Sometimes you have to endure raised eyebrows and not doing the sexy thing for community and engineering reasons.

Props for shipping and maintaining a thing that people use and care about. That is hard. Everyone got raised eyebrows but no one got MRs.

Re: Let’s Talk about PAKE (2018)

#43

Post by nly »

gdavisson wrote: post #41
nly wrote: post #25

Earlier quoted context omitted.

> PAKE doesn't share the password with thr server. The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline. I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.

A server may store the password hashed, but in a password-over-TLS flow the password is received by the server in plaintext. It is only encrypted on the wire (& the network stack). Look at all the places in a standard authentication flow where the plaintext password is exposed: - Any TLS-stripping middleboxes on the client's network. (My personal security nightmare is that someone finds a vulnerability in one of thos…

I agree that with the likes of industrial scale MITM (Cloudflare) in the pipe it's not good... but remember Cloudflare also has access to your session tokens, not just your password, so a PAKE might not help without seriously reworking how we do sessions also.

I'm less concerned about corporate level MITM since in those scenarios the MITM already owns the clients. Regardless of protocol, it's a lost cause there.

Re: Let’s Talk about PAKE (2018)

#44

Post by mabbo »

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…

The issues is that passwords are red data and you want to minimize the number of places red data exists and can be leaked.

Consider the Twitter issue mentioned in the article. Logging inputs is a very common thing and is often important for security auditing later. But if you add it, you need to make sure you're censoring passwords. If you do that wrong, or something around it later changes, you're leaking plaintext passwords to your logs.

And that's just one angle. There's also db compromise. DB snapshot/backup compromise. There's a dozen more dangerous attack surfaces we haven't even thought of yet.

PAKE means that no matter what you do, you can't leak a plaintext password because you don't know it. That's why it's powerful.

Re: Let’s Talk about PAKE (2018)

#45

Post by tialaramex »

collegeburner wrote: post #6

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?

I don't know why OPAQUE was chosen in this 2018 article, but OPAQUE was eventually selected as CFRG's preferred asymmetric PAKE

PAKEs are a fairly specialist protocol. If you don't need to use human memorable passwords then you should not do so. There are cases where you can't bootstrap some other means but you do have, or can agree, a human memorable password and PAKEs are a good choice then.

So there are lots of problems where a PAKE would be better than what you have today, but what you have today is rubbish and it makes more sense to do the Right Thing™ instead.

I don't want Hacker News to authenticate me with a PAKE instead of crummy password-in-a-form technology, the right thing is WebAuthn.

Even for one of the places a PAKE is commonly used today WiFi (WPA3) this is true. The PAKE is used to make the crummy WiFi shared password scheme less broken, and it's an improvement over prior approaches. But just not doing PSKs at all is better. An EduROAM participant from say, CalTech using WiFi on a trip to Rome isn't relying on a PAKE, they are doing full user authentication proxied to CalTech to authorise access to the Roman WiFi.

Re: Let’s Talk about PAKE (2018)

#46

Post by tialaramex »

sedatk wrote: post #21

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.

OPAQUE was chosen because the name OPAKE already existed, and it's an Oblivious PAKE. So, it does not form an acronym.

Re: Let’s Talk about PAKE (2018)

#47

Post by jedisct1 »

Besides pairing devices, there isn't a lot of actual use cases for balanced PAKEs.

Some PAKEs have the interesting property that passwords are never sent to servers.

Which is definitely a good thing. Insider threats and excessive logging are real threats, and passwords can be leaked before being hashed.

However, these PAKEs still don't prevent brute force attacks. Sure, every attempt requires an interactive protocol. But if you are operating the server, or have a copy of the database (including keys for salt-hiding PAKEs), that can be done locally, and the PAKE doesn't provide any value.

What I would love to see is a standard scheme that requires at least a third party. A multi-party computation, relying on servers operated by different entities, that don't know about each other's secrets, and can be semi-honest. So, if any of these parties gets compromised (even internally), this doesn't reveal anything about passwords or the data held by the other party.

All the pieces to build this exist, but an actual protocol doesn't.

Re: Let’s Talk about PAKE (2018)

#48

Post by tptacek »

cvwright wrote: post #29
tptacek wrote: post #28

Earlier quoted context omitted.

I don't understand why you would ever protect an encrypted archive of keys stored serverside with a passphrase authenticated from a password hash stored on the server (which is effectively how a PAKE works). It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. (SRP is pretty much dead now, for what it's worth).

Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is laz…

I am having trouble following the security design here. If the server ever decrypts this data, it doesn't matter how you store the keys. If it doesn't, the encryption keys never need to leave the client.

I think you need to start by very clearly defining the security model you are trying to design, and then start talking about constructions to throw at it.

I don't know what the shrug means, but you shouldn't use SRP in a 2021 design.

Re: Let’s Talk about PAKE (2018)

#49

Post by tptacek »

cvwright wrote: post #26
tptacek wrote: post #2

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/

So the two main problems with SRP, according to this post, are: 1. It exposes the salt and verifier to the adversary, enabling a brute-force search for the password 2. It relies on the discrete log problem, and is thus vulnerable to quantum computers In practice, I don't buy the argument that either one of these is a deal breaker, as long as you do SRP in a "modern" way, ie you're not tied verbatim to some 1997 versi…

I don't understand what you're trying to say here. It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP.

You're certainly not correct that the article is saying SRP is flawed because it "relies on the discrete log problem", as ECDLP-based PAKEs are also vulnerable to QC.

Re: Let’s Talk about PAKE (2018)

#50

Post by bastawhiz »

mabbo wrote: post #44
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…

The issues is that passwords are red data and you want to minimize the number of places red data exists and can be leaked. Consider the Twitter issue mentioned in the article. Logging inputs is a very common thing and is often important for security auditing later. But if you add it, you need to make sure you're censoring passwords. If you do that wrong, or something around it later changes, you're leaking plaintext…

PAKE also means one more thing that can break and one more library (actually two libraries, unless you're running Node) that can have serious security issues.

Those are tradeoffs, and the purism of never handling red data doesn't necessarily offset its costs. Especially in a small organization. If you're going to spend N hours on security, what's going to give you the biggest bang for your buck? PAKE would hardly crack my top 20, honestly. Are you confident your deps are updated quickly after CVEs are published? Is your server's kernel up to date? Are you sure your security group configuration is correct right now? Do you have lint rules to protect against XSS issues? PAKE makes a really bad issue slightly less bad, but there's thousands of things that you could be doing that meaningfully prevent issues in the first place.

If 0.5% of your users get a JavaScript exception from the PAKE library, are you confident that you can fix it? What's the cost of those users not being able to log in (and/or churning)?

When it comes to low hanging fruit at most small businesses, handling of plaintext passwords delivered over a secure connection is small potatoes compared to the myriad of other serious security challenges you're likely facing.

Post reply on HN