<div dir="auto">Den 7 feb 2017 20:18 skrev "Joseph Kilcullen" <<a href="mailto:kilcullenj@gmail.com">kilcullenj@gmail.com</a>>:<br><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a link to my original post back in June 2016. You people never told me why my solution is wrong.<br>
<br>
So please tell me. Why is my solution wrong?<br>
<br>
Here's a link to the latest version of the paper: <a href="https://arxiv.org/abs/1511.03894" rel="noreferrer" target="_blank">https://arxiv.org/abs/1511.038<wbr>94</a></blockquote></div></div><div dir="auto"><br></div><div dir="auto">(edited to not top post this time)</div><div dir="auto"><br></div><div dir="auto">What's with the attitude? <div dir="auto"><br></div><div dir="auto">Trusted interfaces is an old idea. You have at least that idea right. </div><div dir="auto"><br></div><div dir="auto">Qubes OS is a recent example of using trusted interfaces; </div><div dir="auto"><a href="https://www.qubes-os.org/screenshots/" target="_blank">https://www.qubes-os.org/<wbr>screenshots/</a><br></div><div dir="auto"><br></div><div dir="auto">Browser based controls have been proposed previously. Problem is that that isn't enough by itself if such interfaces aren't used everywhere and if the the users are careless. You need to users to be educated on how it works, and proactive. <br></div><div dir="auto"><br></div><div dir="auto">Also, it would work better if it used trusted inputs mixed with phishing proof authentication protocols like FIDO's U2F / UAF that binds the authentication response to the TLS session, blocking replay attacks and MITM. This way the user secret isn't useful anywhere outside his own browser. </div><div dir="auto"><br></div><div dir="auto">Consider a process such as having the browser always tell you "on this site, press the interception safe keyboard button X to open the login prompt", and using something like a YubiKey that require you to press its button to perform the challenge-response protocol, and then to ask the user to enter his PIN / password to prove it is him at the computer. </div><div dir="auto"><br></div><div dir="auto">This may be combined with a unique and secret color scheme per user to further reduce the risk of forgery in the case of targeted attacks. </div><div dir="auto"><br></div><div dir="auto">The user would be conditioned that the website can't open a safe login prompt by itself and that only the browser provides the prompt, and that he shouldn't share his secrets (password, PIN) outside it. It is also simpler. </div><div dir="auto"><br></div><div dir="auto">The more similar the correct process is every time, the more likely it is that the flaws of an attempt at phishing will alert the user that something is wrong.</div><div dir="auto"><br></div><div dir="auto">Meanwhile a fake website can not in any anyway use your credentials in any manner without stealing them directly, which would require hacking your browser to directly forge the 2FA request. Otherwise, compromise requires stealing your hardware token and also figuring out your password or PIN. </div><div dir="auto"><br></div><div dir="auto">Just getting your memorized credentials (PIN) alone gets them nowhere if they can't also get the accompanied 2FA secrets / hardware. </div><div dir="auto"><br></div><div dir="auto">In your scheme (if I read it right), a user just have to be forgetful once and it fails. Sending plain passwords is a dated solution that should be deprecated. </div></div></div>