"If a user attempts to login to a malicious site accidentally or because they were tricked by a similar but different name, the malicious server will only gain knowledge of a derived public key. The attacker will not be able to impersonate the user at any other server, or even on the compromised server, because the attacker has not discovered either the user's private key for connecting to the compromised server, or the user's password that could be used to derive the private key on this or other servers."
Doesn't this assume a lot about the state of the internet? I mean a phishing attack could easily harvest the user's password, then the attacker effectively has their private key. Unless every user were trained well on how to determine whether the connection can be trusted, but that's still a problem today in 2015 even with https.
and the web browser would allow you to enter your credentials in a secure, NATIVE window. (At least secure from web stuff - keyloggers get a lot more powerful under this scheme.)
If it works as advertised, it's quite nice. Personally, I think this is very close to what we need.
I will note I still probably wouldn't use it because if your password is exposed, then you're screwed. It is very close though. A hardware element or something might mitigate this enough.
Ok, but how would a native window prevent an undereducated user from naively entering their password into an attacker's spoofed login form? In my mind this strategy more or less kicks the ball down the field as opposed to revolutionizing security.
Would this not still be phishable? All an attacker would have to do is make a website look enough like the real thing, then use a plain <form> element and capture the submitted form content.
I would think an out of browser app might work better for that task.
If this is traditional public-key crypto, having the password does nothing for the attacker without the private key. But I didn't watch his "technical details video" so I don't know what he's actually implemented. He mentions that getting the user's password would allow you to derive the private key, which makes no sense.
That's exactly the problem. The private key and the password are effectively 1-1. So if you can phish the password, you have the private key. This solves nothing.
No, that's not a problem at all; the key appears to be derived from more than just the password. The only weak spot is if you can run arbitrary code on the user's PC.
(I'm going by the textual description on the linked page as there doesn't seem to be a more detailed or formal one)
The key, as I understand it, is derived from a combination of the password and other deterministic elements, like the host URL. I suppose it's supposed to be ethereal, generated only for the session and the disposed after the user logs out. But for it to work, the user would have to be able to generate the exact same key on other machines using the same password. In which case, all an attacker needs to obtain the private key is the password and the vulnerability to phishing remains.
Doesn't this assume a lot about the state of the internet? I mean a phishing attack could easily harvest the user's password, then the attacker effectively has their private key. Unless every user were trained well on how to determine whether the connection can be trusted, but that's still a problem today in 2015 even with https.