12 ms·
It's true that if your browser and websites supported SRP-EC-Scrypt, you would know that they stored things "securely". However, this won't solve the problem of
by dchest 12y ago
It's true that if your browser and websites supported SRP-EC-Scrypt, you would know that they stored things "securely". However, this won't solve the problem of people using weak passwords and people using the same password for different websites. If you use strong passwords and don't reuse them, you already know your risks.
As for your second point, I don't understand it. Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? What's the use of it? This sounds strangely similar to this idea: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721
> We need to change our trust models. I trust eBay as an organisation to offer me a service. I don't trust the web stack or their servers.
Then passwords don't matter, because you assume that attackers already can do everything with your eBay account.
- nly 12y ago> If you use strong passwords and don't reuse them, you already know your risks. Nobody does this. Geeks who use password management are are an extreme minority, and solutions like LastPass are crock that solve the same problem by papering over infrastructural failings and mean users are never completely free to move. Anecdotally I believe people typically use a 'good password' for banking etc, and a handful of lazy passwords. Cryptographically speaking, they're all weak of course, but imho people are better off with knowing one or two really good passwords (I used a 12 character mixed case password containing symbols entirely from QWERTY induced muscle memory) and letting their browser deal with derivation for different endpoints. > Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? Not SRP specifically. Forget SRP. What I mean is generally that any user public key (whether it was originally derived from a user secret like a password or not) can be used by an organisation for online encryption and authentication and offline decryption, where data can be decrypted by either the organisation using their private key, or by the user using their password.
- dchest 12y agoI agree with you that browsers help can improve security, in general. (Mozilla tried this with BrowserID/Persona, but failed.) As for your second point, I still don't understand it :-) It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate.
- nly 12y ago> It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate. That's why the solution needs to be built in to web standards like HTTP 2.x and HTML, rather than shimmed in to a javascript library. The original HTTP authentication scheme actually did one thing right, and that was bypassing HTML and Javascript (where any hope of security and privacy is long dead and buried) and going straight to the browser UI.