[tor-dev] Hash Visualizations to Protect Against Onion Phishing
desnacked at riseup.net
Thu Aug 20 13:49:42 UTC 2015
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  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
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:
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 . So for example, TBB could generate a unique UI theme for each
- 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  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
- 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
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!
More information about the tor-dev