[tor-dev] Hash Visualizations to Protect Against Onion Phishing

[Jeff Burdges]

I first learned about key poems here : 
https://moderncrypto.org/mail-archive/messaging/2014/000125.html
If one wanted a more language agnostic system, then one could use a
sequence of icons, but that's probably larger than doing a handful of
languages.

I once encountered an article claiming that SSH randomart doesn't work
well.  I'm not sure about that article locate or correctness however.
Random art might work if you used icons, ala pink panda riding a blue
horse eating a green lion, but this grows harder to implement.  In fact,
algorithms that invent or merge human faces might work for people who
remember faces well. 

If we believe key poems might work, then we could build a firefox
extension that does them, and make the code quite readable.  Anyone with
more interest in doing the human research could pick up where we leave
it.

Jeff

p.s.  I briefly mentioned this general application of key poems in the
Future Onion Addresses and Human Factors thread too.  I don't recall
that thread pursuing the matter though.





On Thu, 2015-08-20 at 16:49 +0300, George Kadianakis wrote:
> Hello,
> 
> this mail lays down an idea for a TBB UI feature that will make it slightly
> harder to launch phishing attacks against hidden services. The idea is based on
> hash visualizations like randomart [0] and key poems:
> 
>             -------------------
> 			|       o=.       |
> 			|    o  o++E      |
> 			|   + . Ooo.      |
> 			|    + O B..      |
> 			|     = *S.       |
> 			|      o          |
> 			|                 |
> 			|                 |
> 			|                 |
>             -------------------
> 
> The idea came up during a discussion with Jeff Burdges in CCC camp.
> This is a heavily experimental idea and there are various unresolved research
> and UX issues here, but we hope that we will motivate further study.
> 
> The aim is to make it harder to phish people who click untrusted onion links.
> Think of when you click an onion link on a forum, or when a friend sends you an
> onion URL.
> 
> The problem is that many people don't verify the whole onion address, they just
> trust the onion link or verify the first few characters. This is bad since an
> attacker can create a hidden service with a similar onion address very
> easily. There are currently ready-made scripts that people have been using to
> launch impersonation attacks against real hidden services.
> 
> The suggested improvement here is for TBB to provide additional visual
> fingerprints that people can use to verify the authenticity of a hidden service.
> So when TBB connects to a hidden service, it uses the onion address to generate
> a randomart or key poem and makes them available for the user to examine.
> 
> Here is an experimental mockup just to illustrate the idea:
> 
>     https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png
> 
> The idea is that you hash (or scrypt!) the onion address, and then you make a
> visualization using the hash output. This forces the phishing attacker to
> generate a similar onion address _and_ similar hash visualizations. We assume
> that this will be harder to do than simply faking a similar onion address, which
> increases the startup cost for such an attacker.
> 
> This is the basic concept. Now, here are some thoughts:
> 
> - What hash visualizations can we use here?
> 
>   The SSH randomart is an obvious idea, and we can even have it colored since we
>   are not in a terminal.
> 
>   Then we have the key poem idea, which generates a poem from a key. I don't
>   think this is used by a deployed system currently.
> 
>   Then we could imagine music-based hash fingerprints, where the onion address
>   corresponds to a small tune that is played when you visit an onion.
> 
>   Then there are even more crazy ideas like the "Dynamic Security Skins"
>   paper [1]. So for example, TBB could generate a unique UI theme for each
>   hidden service.
>   
> - Of course, none of the above ideas is perfect. Actually most of them suck.
> 
>   For example, when it comes to randomart, many people are colorblind to some
>   degree and most people are not good at recognizing subtle color differences.
> 
>   Furthermore, given a randomart, it's easy [2] to generate similar
>   randomarts. However we hope that most of those similar randomarts will not
>   correspond to a public key that is similar to the original one. 
> 
>   When it comes to key poems, given even a moderately sized dictionary leads to
>   pretty big poems. We are talking about poems of 24 random words, which is not
>   something that most people can remember.
> 
>   Much more research needs to be done here.
> 
> - Even though all these techniques are flawed in some way or another, we hope
>   that by deploying them we increase the cost of the attacker.
> 
>   If a few of these techniques are implemented, a phishing attacker will have to
>   spend time generating similar visualizations, because she does not know
>   whether the user actually looks at them and which one the user prefers.
> 
>   Also, this feature only requires a TBB addon/patch and no modifications to the
>   Tor protocol whatsoever, which makes it slightly easier to prototype and
>   experiment with.
> 
> - On the other hand, this might be a terrible idea for multiple reasons.
> 
>   From the UX perspective, it will confuse people who don't expect to see crazy
>   visuals or poems on their browser. Our hope here is that this feature will be
>   hidden by most users, and will only be used by people who understand it.
>   However, this exact logic is what causes bad UI.
> 
>   Also, from a security perspective this might encourage people to not spend
>   time to verify the whole onion address (currently 16 chars, but will be
>   extended to 54 chars or so with prop224), and instead rely on the stupid
>   randomart.
> 
>   Some real UX research needs to be done here, before we decide something terrible.
> 
> - Finally, a positive thing with this idea is that it nicely complements
>   directories of onion addresses like search engines and human-memorable
>   systems. In the future, people who visit the same onion address using a search
>   engine all the time, will have an extra way of verifying its authenticity.
> 
> In any case, this is just a crazy pants idea, so please send your feedback to
> make it more useful, or to kill it completely!
> 
> Cheers!~
> 
> [0]: http://undeadly.org/cgi?action=article&sid=20080615022750
>      http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf
> 
> [1]: http://www.eecs.berkeley.edu/~tygar/papers/Phishing/Battle_against_phishing.pdf
> 
> [2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150820/6c235551/attachment-0001.sig>