5 ms·
If you are an active server attacker, you can simply disable hashing and store passwords in clear. With SRP you cannot.
by the_clarence 8y ago
If you are an active server attacker, you can simply disable hashing and store passwords in clear. With SRP you cannot.
- panopticon 8y agoMaybe 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.
- 8y ago
- 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
- fileworm 8y agoIt's worse than that. In the web app use case, if the browser is sending cleartext passwords to the server, all an attacker has to do is hijack the server IP with BGP, get a DV SSL cert and slurp up all the passwords.