5 ms·
Maybe this is naive, but if the server is compromised such that an attacker can circumventing your hashing function can't the attacker just send some JS down to
by panopticon 8y ago
Maybe this is naive, but if the server is compromised such that an attacker can circumventing your hashing function can't the attacker just send some JS down to the client that records the password before it's hashed?
- tptacek 8y agoYes, you can't securely deploy a PAKE using browser javascript. If it's web applications you want to secure, your users will have to install something to make a PAKE secure.
- cipherboy 8y agoThat something can be minimized to "a browser" when SPAKE+2FA support is finalized in Kerberos. Admittedly, only really useful for enterprise clients who already have krb5 deployed, but still it is something better than JS.
- tptacek 8y agoThe word "admittedly" is doing a lot of work in that sentence.
- lucb1e 8y agoThis still sounds the same as client side hashing to me. At some point I tried talking to people to make client side hashing an option in <input type=password hashmethod=X>, but nobody cared more than saying "yeah sounds good" when prompted. If this would have been implemented and would have become mainstream, browsers can warn if a site (suddenly) doesn't use it, much like warning for http (or even pinning a la hsts). So as it is, it indeed cannot be done securely in browsers.
- tptacek 8y agoApart from the fact that I think client-side hashing is silly, I agree with you; we're saying the same thing about the feasibility of PAKEs in browser applications.
- the_clarence 8y agoIt’s not silly if it’s done outside of browsers I’d say. But with browsers it's tricky to implement (and its where it would be useful)
- tptacek 8y agoIt's silly because as soon as you're doing something custom clientside, you might as well just use a PAKE.
- the_clarence 8y agoI don't agree. PAKE is useful to setup a secure channel. But if you already have a secure channel that doesn't need client authentication, and you want to augment it with client authentication, this is easier to implement
- fileworm 8y agoYour proposal is equivalent to sending plaintext passwords, because the client-calculated hash can be used like a password.
- tptacek 8y agoNo, it's not. You can capture the password-equivalent authenticator, but (assuming a strong KDF) not easily reverse it back out to a password that could be used at other sites, which is the only reason anyone cares about hiding passwords from servers in the first place.
- Ar-Curunir 8y agoThis doesn't prevent dictionary attacks, since there's no salt involved, AFAIK.
- lvh 8y agoSince you're not worried anymore about burning the server-side resources, you prevent the dictionary attack in this scenario with a punitively expensive KDF. (Note: I am not saying this is a good idea! It's OPAQUE but worse.)
- lucb1e 8y agoIn the draft spec I wrote it would be salted by default with the origin (proto+domain+port), and could be overridden (in case a site changes domains) by a parameter. That would act as salt for the site, so that you have a unique hash for each site without having to keep (and sync to other browsers and computers) a database of salts.
- the_clarence 8y agoi like your idea a lot
- AlexCoventry 8y agoThe blog post points out that client-side hashing exposes you to ahead-of-time dictionary attacks, because you have to reveal the salt in the initial phase of the challenge.
- the_clarence 8y agoYes you can. You just need to download the page and have SRI to serve the javascript. Of course it’s harder to update but now you’re emulating native apps and their “added” security
- lvh 8y agoThis is technically true, but the UX for this is so horrendous it's hardly worth taking seriously. If people are willing to put up with bad UX we could instead use TLS client certificates, which are still _much better_ than saving a page that has JS SRI in it (at least it's in the browser!) and has _much better_ cryptographic properties. (And that's assuming that you could somehow get the origin issues right.)
- the_clarence 8y agoThat's the UX of native apps
- orf 8y agoDownload as in wget it? That would break for all kinds of reasons (CORS, CSRF etc), and SRI does nothing if the attacked controls page generation.
- the_clarence 8y agoIf it is made to be downloaded, no
- LukeShu 8y agoNo you can't. The security improvement of PAKE over traditional HTML forms + TLS is that the server never knows the password plaintext; the threat model is a compromised first-party server. If the server is compromised, it can just change the SRI hashes that it sends to the client. SRI is only an effective protection against compromised third-party services.
- lvh 8y ago