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

[Jeff Burdges]

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



-------------- 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/20150821/c6852a82/attachment.sig>