remote-help-assistant team mailing list archive

[Andrew Sayers <andrew-bugs.launchpad.net@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey list,

New contributor Erpiu has recently filed a couple of important issues
with the way assistant handles SSH keys, which I'd like to get people's
opinions on.  I think we need to solve both at the same time, so I'll
first explain the issues, then suggest some solutions.

Erpiu and I have discussed these issues a bit in
https://answers.launchpad.net/remote-help-assistant/+question/64030 and
https://bugs.launchpad.net/remote-help-assistant/+bug/340490, but I'll
try to explain them quickly here.

First issue: on pages 5 and 6 ("check your/their password"), new users
are told "passwords based on a series of random dates", then "their
identification is new", then asked to tick "this key belongs to someone
I trust".  In other words, the assistant uses the words "password",
"dates", "identification" and "key" to refer to basically the same
things, which is bound to be confusing.  Also, talking about "keys" is
likely to confuse non-technical users, whereas talking about anything
else is likely to make technical users think we're using some homebrew
security scheme.


Second issue: if you accidentally delete your ~/.remote-help-assistant/
directory, people you've shared with before will be warned that your key
has changed.  In versions of the assistant up to 0.1.2, that warning was
permanent - if you said you trusted the new key, it would warn you again
the next time anyway.  As a temporary measure, 0.1.3 asks you once, then
trusts the new key.

A bad key warning could be the only sign that you're being attacked, so
it's very important we get this right.  The 0.1.2 solution is no good,
because it trains people to ignore security warnings.  The 0.1.3
solution isn't much better, because users could easily tick the box and
click 'forward' without reading the text.



Based on the above, here are some suggestions for things we could do:

1) create a shell script for manually sharing keys and IP addresses.
That would let you go round to a friend's house and set the assistant
up, install your key and grab theirs, go home and install their key,
then share a session without ever having to do key exchange or tell them
an IP address.

2) add a configuration option (not editable from within the assistant),
which blocks new keys from being trusted.  Pages 5 and 6 can be removed
altogether for those users.  New keys can still be added by technical
users sitting at that computer.

3) include documentation, linked from page 1 ("Remote help assistant").
 The documentation would cover:

 * What the assistant is for (and isn't for), how to use it etc.
 * How to use the script discussed in (1) and (2)
 * How to make a custom Ubuntu CD (using the Ubuntu Customisation Kit),
   so you can get the assistant and your key baked in to a CD at
   install-time.
 * More information about the connectivity options currently crammed in
   on page 3 ("General information")
 * How the date-based security system works (SSH, keys, etc.)
 * A quick primer about public key exchange
 * issues with public keys being changed

4) on pages 4 and 5 (check your/their password), use terms like
"passwords based on a series of random dates", "these dates are new",
and "these dates belong to someone I trust".  The theory will already be
in the previously-linked documentation, so these pages can afford to be
simple instructions

5) when the assistant sees a bad key, pages 4 and 5 should show the
following message:

=== BEGIN TEXT ===
WARNING: THEIR KEY HAS CHANGED!

The person you are talking to has different dates this time.

Impersonating a friend's voice is well beyond the capabilites of a
cyber-criminal.  To be sure you are not about to be the victim of a
crime, ring the other person and check these new dates over the phone.
=== END TEXT ===

Below that, a toggle button should read "I have checked over the
telephone, I am not being tricked by a criminal".  When that button is
off, the forward button and the "I trust these dates" checkbox are both
greyed out.  If the user continues at this point, the old key is
commented out in the "known_keys" file.

Requiring the user to click on a scary-looking button seems like the
best trade-off between security and ease-of-use.  Compared to the
alternatives that were discussed on Launchpad, I think the oddness of a
push-button, the unusually stark language, and the simplicity would be
more likely to reach users that are sleepwalking through the process.

	- Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJvu/yGRQTxegE/G4RAtDTAJ4n98N+HTvlvIMDTcwuv7nSuDiVTACghnKF
davynFQs1onF+Rvcsv3FmXY=
=MyBa
-----END PGP SIGNATURE-----