<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 14 feb. 2017 21:08 skrev "Joseph Kilcullen" <<a href="mailto:kilcullenj@gmail.com" target="_blank">kilcullenj@gmail.com</a>>:<br type="attribution"><blockquote class="m_5576344132084924104m_-2877528992720670885m_2444787067904509412m_-4659507930482592807quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_5576344132084924104m_-2877528992720670885m_2444787067904509412m_-4659507930482592807quoted-text">On 13-Feb-17 3:29 PM, Theodore Ts'o wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The above is something which *is* applicable to your solution.  If you<br>
don't believe it, or believe that your solution is somehow special,<br>
you are welcome to bankroll some human factors lab to do a study<br>
specific to your design...<br>
</blockquote>
<br></div>
True but I figured people who understand cryptography should 'get it' that it's just a shared secret.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We get it. But many of us knows it isn't enough, which is why we skipped right to trying to explain why it isn't enough. </div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">HCISec is the field of study. Human computer interaction studies, focused on security. </span><br></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="m_5576344132084924104m_-2877528992720670885m_2444787067904509412m_-4659507930482592807quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since the image is shared between 'your web browser' and 'you' a MITM attack would involve the criminal standing between you and your computer monitor!! I'm sure this happens but its not called a phishing attack.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Shoulder surfing. Or perhaps just abusing the graphics card to steal the image buffer? </div><div dir="auto"><br></div><div dir="auto"><a href="http://slashdot.org/story/305073" target="_blank">http://slashdot.org/story/3050<wbr>73</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="http://ieeexplore.ieee.org/document/6956554/" target="_blank">http://ieeexplore.ieee.org/doc<wbr>ument/6956554/</a></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="m_5576344132084924104m_-2877528992720670885m_2444787067904509412m_-4659507930482592807quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With my solution a MITM attack must remove TLS entirely or substitute a new TLS certificate. Either way the user, or your browser, will see something is happening. The login window won't appear if TLS is missing. If a new certificate is used then who's identity or CA will be used in it? The computer user will see the fake identity named on the login window.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">But they won't. They typically don't notice and and don't know what to look for. </div><div dir="auto"><br></div><div dir="auto"><a href="https://en.wikipedia.org/wiki/Change_blindness" style="font-family:sans-serif" target="_blank">https://en.wikipedia.org/wiki/<wbr>Change_blindness</a></div><div dir="auto"><br></div><div dir="auto"><a href="https://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/" target="_blank">https://arstechnica.com/securi<wbr>ty/2015/03/mris-show-our-<wbr>brains-shutting-down-when-we-<wbr>see-security-prompts/</a></div><div dir="auto"><br></div><div dir="auto">And phishing works because people slip up. People forget. People become tired. </div><div dir="auto"><br></div><div dir="auto"><a href="http://ieeexplore.ieee.org/abstract/document/6894474/" target="_blank">http://ieeexplore.ieee.org/<wbr>abstract/document/6894474/</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="http://www.usablesecurity.org//emperor/" target="_blank">http://www.usablesecurity.org/<wbr>/emperor/</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="https://www.schneier.com/blog/archives/2016/10/security_design.html">https://www.schneier.com/blog/archives/2016/10/security_design.html</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="https://www.internetsociety.org/doc/neural-signatures-user-centered-security-fmri-study-phishing-and-malware-warnings">https://www.internetsociety.org/doc/neural-signatures-user-centered-security-fmri-study-phishing-and-malware-warnings</a></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Oh, and did anybody mention dyslexics yet? </span></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="m_5576344132084924104m_-2877528992720670885m_2444787067904509412m_-4659507930482592807quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right now users look for a picture of a padlock! If pictures of padlocks are proper cryptography authentication mechanisms then find me a book, or paper, which documents this cryptography authentication mechanism. Or an army which uses this tea leaf reading level cryptography solution!<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It has the same practical effect if it has a protected UI surface to render in. Such as if the URL bar can't be hidden. </div><div dir="auto"><br></div><div dir="auto">The custom image just doesn't beat a custom color theme. In particular since it would be shared for everything you do. </div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">As previously explained, the names will never be more meaningful than the domain name itself. </span><span style="font-family:sans-serif">There's no practical chance you'll recognize the organization name as fake if you didn't react on the domain. </span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">The image has no effect on security. There's nothing that it does that you can't achieve with better URL domain highlighting (perhaps again with a unique color scheme, to prevent forgery?). </span><span style="font-family:sans-serif">The image just says "read this name and see if it is right", which we already know don't work. </span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">I</span>t also literally does nothing meaningful to protect you if you share the raw password with the site anyway - the presence of a unique personal image does nothing if you already failed to identify the domain as fake. The site will be getting your password anyway.</div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">Muscle memory is infinitely more reliable than depending on awareness and recognition. Make it mentally expensive to do the wrong thing and cheap to do the right thing!</div><div dir="auto"><br></div><div dir="auto">U2F / UAF which binds to both the domain name / certificate and TLS session is infinitely more effective. You just can't get it wrong! </div><div dir="auto">You may call this complexity, but it is the right kind of complexity that helps us. It is already implemented and works. The design is fairly simple too! It doesn't change anything outside requiring a small addition to the browser and server. It doesn't modify the TLS protocol or CA behavior or certificates, it uses them as they already are. </div><div dir="auto"><br></div><div dir="auto">Using it means<span style="font-family:sans-serif"> that *you authenticate to the browser* and not to the server (there's your shared secret!), while the browser securely authenticates to the server on your behalf (based on which server it is talking to). </span></div><div dir="auto"><br></div><div dir="auto">Forcing users to choose and remember images and always pay attention is a UX complexity that will fail. </div><div dir="auto"><br></div><div dir="auto">And forcing a change in CA policies will fail - there's over 600 intermediate CA:s that needs to all cooperate, as well as all browsers! </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Trusted inputs simply beats automatic prompts and forced awareness. Logins are just like security warnings to people, something to quickly get around - so lets not give the control over them to untrusted parties. </div><div dir="auto"><br></div><div dir="auto">As I said before, requiring that the user uses a secure input to initiate the interaction / login process would be infinitely more secure. </div><div dir="auto"><br></div><div dir="auto">By for example using a key combo <span style="font-family:sans-serif">(or a button on a security hardware token) that</span> can't be intercepted or faked in combination with an authentication protocol that can't be phished (like U2F / UAF), you train the user to only use prompts he intentionally triggered and simultaneously help prevent unwanted authentication / authorization of anything he didn't intend (like not accidentally approving a bank transfer). </div><div dir="auto"><br></div><div dir="auto">It not only blocks phishing and preserves the password protection against nosy colleagues, but it also provides a defense against for example XSS attacks (as does other 2FA) and exploits against password autofill;</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/anttiviljami/browser-autofill-phishing">https://github.com/anttiviljami/browser-autofill-phishing</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="https://www.theguardian.com/technology/2017/jan/10/browser-autofill-used-to-steal-personal-details-in-new-phising-attack-chrome-safari">https://www.theguardian.com/technology/2017/jan/10/browser-autofill-used-to-steal-personal-details-in-new-phising-attack-chrome-safari</a><br></div></div>