Hash Visualizations to Protect Against Onion Phishing
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.... [2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf
W dniu 20.08.2015 o 15:49, George Kadianakis pisze:
Some real UX research needs to be done here, before we decide something terrible.
Just curious, has anybody seen any cognitive studies on the SSH randomart visualisation? I always found them impossible to remember. Perhaps adding a bit more color could help...
Jacek Wielemborek <d33tah@gmail.com> writes:
W dniu 20.08.2015 o 15:49, George Kadianakis pisze:
Some real UX research needs to be done here, before we decide something terrible.
Just curious, has anybody seen any cognitive studies on the SSH randomart visualisation? I always found them impossible to remember. Perhaps adding a bit more color could help...
Hm. Indeed. I can remember the general shape and edges of my SSH server's key, but not any details. I doubt I would remember the randomart of like 10 onion websites, especially if I didn't visit them regularly. But maybe I would remember the randomart of my webmail better than my SSH server's.
On Thu, 20 Aug 2015 17:02:24 +0300 George Kadianakis <desnacked@riseup.net> wrote:
Jacek Wielemborek <d33tah@gmail.com> writes:
W dniu 20.08.2015 o 15:49, George Kadianakis pisze:
Some real UX research needs to be done here, before we decide something terrible.
Just curious, has anybody seen any cognitive studies on the SSH randomart visualisation? I always found them impossible to remember. Perhaps adding a bit more color could help...
Hm. Indeed.
I can remember the general shape and edges of my SSH server's key, but not any details.
I doubt I would remember the randomart of like 10 onion websites, especially if I didn't visit them regularly. But maybe I would remember the randomart of my webmail better than my SSH server's.
What would be useful here is the number of onion addresses an average user visits. If it's small, something like this would probably be sufficient: 0. Browser generates/stores a long term salt. 1. On onion access, calculate SHAKE(salt | onion address) map that to a poker hand (5 card draw). P(52,5) = 311,875,200 C(52,5) = 2,598,960 2. Goto 1. Benefits: 0. Collisions between addresses are unlikely and don't weaken the scheme (though it will be confusing to the user that does encounter the situation). 1. Brute-forcing is mitigated via the per-client salt. 2. Incomplete recall still useful (User needs to forget all of order, suite, and card value). 3. Easy to memorize. 4. Easy to extend up to a point. 5. Can probably display it with fonts present on the system (or the one that will be bundled). Cons: 0. Having to propagate the salt value if the user uses multiple boxes is somewhat annoying. 1. May get confusing to remember lots and lots of onions->hand mappings. 2. No "canonical" visualization that can be shared across users. 3. Something Yawning randomly made up before going to bed. Regards and good night, -- Yawning Angel
On Thu, Aug 20, 2015 at 02:41:51PM +0000, Yawning Angel wrote:
What would be useful here is the number of onion addresses an average user visits. If it's small, something like this would probably be sufficient:
0. Browser generates/stores a long term salt.
1. On onion access, calculate SHAKE(salt | onion address) map that to a poker hand (5 card draw).
P(52,5) = 311,875,200 C(52,5) = 2,598,960
2. Goto 1.
The per-browser salt is a good way to prevent similar-hash attacks, but of course will go astray if the user reinstalls her Tor Browser or has multiple devices. I'd caution about the poker hand, though. One year when I taught first-year undergraduate CS, we included an assignment that had to do with decks of cards and card games. A surprising number of people had never seen decks of cards before, and were unfamiliar with the concept. I did not observe whether the (un)familiarity was correlated with what part of the world they came from. Perhaps a notification "You've never visited this site before" that pushes down from the top like some other notifications might go a long way?
On Thu, Aug 20, 2015 at 11:00:51AM -0400, Ian Goldberg wrote: | I'd caution about the poker hand, though. One year when I taught | first-year undergraduate CS, we included an assignment that had to do | with decks of cards and card games. A surprising number of people had | never seen decks of cards before, and were unfamiliar with the concept. | I did not observe whether the (un)familiarity was correlated with what | part of the world they came from. | | Perhaps a notification "You've never visited this site before" that | pushes down from the top like some other notifications might go a long | way? Whatever we choose, it's essential to test early and often with real people who are being exposed to it for the first time, and in a way that makes it possible for them to critique the UI without being made to feel stupid. As Ian points out, real people surprise you in surprising ways. Adam
On Thu, 20 Aug 2015 11:00:51 -0400 Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Thu, Aug 20, 2015 at 02:41:51PM +0000, Yawning Angel wrote:
What would be useful here is the number of onion addresses an average user visits. If it's small, something like this would probably be sufficient:
0. Browser generates/stores a long term salt.
1. On onion access, calculate SHAKE(salt | onion address) map that to a poker hand (5 card draw).
P(52,5) = 311,875,200 C(52,5) = 2,598,960
2. Goto 1.
The per-browser salt is a good way to prevent similar-hash attacks, but of course will go astray if the user reinstalls her Tor Browser or has multiple devices.
Yeah, that's a downside. I suspect it can be fairly short but I don't have a solid basis for that suspicion, and it also provides the property of being able to semi-arbitrarily increase the brute forcing difficulty at a latter date.
I'd caution about the poker hand, though. One year when I taught first-year undergraduate CS, we included an assignment that had to do with decks of cards and card games. A surprising number of people had never seen decks of cards before, and were unfamiliar with the concept. I did not observe whether the (un)familiarity was correlated with what part of the world they came from.
It was a hypothetical example. If we're willing to go with the visual equivalent of key poems (which is what my suggestion roughly corresponds to) with a per-client secret to prevent brute forcing, then there's no reason why we couldn't let the user choose a visual representation they're most comfortable with. (My initial example was going to use mahjong tiles. >.>)
Perhaps a notification "You've never visited this site before" that pushes down from the top like some other notifications might go a long way?
People would likely complain about storing "did access foo.onion in the past" type information to disk. I could argue for/against "well, use a per-client keyed bloom filter, false positive rate!!!!", but depending on the adversary model, people will probably (rightfully) be uneasy at the thought of persisting even that. The moment people are willing to store "I accessed this onion in the past", I'm inclined to think "this is functionally equivalent to the user bookmarking said onion". Regards, -- Yawning Angel
A per browser salt is a wonderful idea. It's basically impossible to fake even small key poems or whatever if you cannot guess their salt. Just some thoughts : - The salt should be a text field users can interact with easily. It could be displayed prominently in the extensions config, or even with the key poem or whatever. - Initially (no pre-existing salt) the salt should be set to contain a few dictionary words, maybe using a call to key poem routines. Using dictionary words makes it easier for users to copy the salt between machines. - Ideally, the initial salt should be set using machine specific information, like CPU ids or default mac address or whatever, instead of a temporary random number, so a clean reinstall of the operating system should produce the same salt. - Upgrades should attempt to preserve the salt. Tails should attempt to persist the salt too, but ideally TBB should produce the same salt when run on under Tails on the same machine without persistent storage. If machine identifiers cannot be used, then maybe Tails could set the salt when the boot image is created. - Documentation should recommend that users who fear targeted attacks set a stronger salt and advice that all users share the same salt across all their machines. There could be buttons to create a random strong salt and reset the salt to the machine's default. - Ideally, the documentation should explain that if you want to compare representations with another person then you should use a temporary salt, so as not to reveal your usual salt. On Thu, 2015-08-20 at 15:47 +0000, Yawning Angel wrote:
It was a hypothetical example. If we're willing to go with the visual equivalent of key poems (which is what my suggestion roughly corresponds to) with a per-client secret to prevent brute forcing, then there's no reason why we couldn't let the user choose a visual representation they're most comfortable with.
Yeah, if there are multiple representations then users could simply select the ones they like. If someone wants to do a research project on visually recognizing key material then they can add an option to the extension. I'd expect card hands, mahjong tiles, etc. suck for most users, btw. I wonder if memes like lolcats might make an good compromise for the different memorability constraints. It could be as simple as an image database with associated keywords, a dictionary, and word transition probabilities. If we've a per browser salt, then one could simply select a unix fortune cookie or something similarly entertaining but low entropy.
Perhaps a notification "You've never visited this site before" that pushes down from the top like some other notifications might go a long way?
People would likely complain about storing "did access foo.onion in the past" type information to disk. I could argue for/against "well, use a per-client keyed bloom filter, false positive rate!!!!", but depending on the adversary model, people will probably (rightfully) be uneasy at the thought of persisting even that.
The moment people are willing to store "I accessed this onion in the past", I'm inclined to think "this is functionally equivalent to the user bookmarking said onion".
Yes exactly. In fact, if you've added the bookmark star to FireFox's toolbar then it changes color when you visit a bookmarked page, so you could already do this by bookmarking the site's root and briefly returning to it to check. Another idea : If the users has added the bookmark star to FireFox's toolbar, and bookmarked anyplace on the site but not the exact page, then the bookmark star changes to another color to indicate the site has been visited before, and lets users quickly find all the bookmarks on that site. Jeff
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....
[2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 20 August 2015 at 09:24, Jeff Burdges <burdges@gnunet.org> wrote:
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.
That led to the attempt to run a usability study on text representations, which kind of fizzled out: https://github.com/tomrittervg/crypto-usability-study The visual systems that are implemented that I'm aware of are: - SSH art of course - Identicons: http://haacked.com/archive/2007/01/22/Identicons_as_Visual_Fingerprints.aspx... - Monsters: http://www.splitbrain.org/projects/monsterid - Wavatars: http://www.shamusyoung.com/twentysidedtale/?p=1462 - Unicorns (really): http://meta.stackoverflow.com/questions/37328/my-godits-full-of-unicorns -tom
I like the idea of a drop down notification type deal that displays that you have not visited this site before. And implement that as a default off option in TBB. This lets the user decide if they accept that tradeoff. On Fri, Aug 21, 2015 at 5:11 PM Tom Ritter <tom@ritter.vg> wrote:
On 20 August 2015 at 09:24, Jeff Burdges <burdges@gnunet.org> wrote:
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.
That led to the attempt to run a usability study on text representations, which kind of fizzled out: https://github.com/tomrittervg/crypto-usability-study
The visual systems that are implemented that I'm aware of are: - SSH art of course - Identicons: http://haacked.com/archive/2007/01/22/Identicons_as_Visual_Fingerprints.aspx... - Monsters: http://www.splitbrain.org/projects/monsterid - Wavatars: http://www.shamusyoung.com/twentysidedtale/?p=1462 - Unicorns (really): http://meta.stackoverflow.com/questions/37328/my-godits-full-of-unicorns
-tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, 20 Aug 2015 at 14:49 George Kadianakis <desnacked@riseup.net> wrote:
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.
Unfortunately, I can no longer find it, but I have seen research that showed this was trivially defeated for most users.
participants (9)
-
Adam Shostack -
Ben Laurie -
George Kadianakis -
Ian Goldberg -
Jacek Wielemborek -
Jeff Burdges -
R. Anthony Lomartire -
Tom Ritter -
Yawning Angel