remote-help-assistant team mailing list archive

[Sebastian Spiess <sebastian.spiess@xxxxxxxxx>]

On Tue, 2009-03-17 at 00:33 +0000, Andrew Sayers wrote:
> -----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-----
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~remote-help-assistant
> Post to     : remote-help-assistant@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~remote-help-assistant
> More help   : https://help.launchpad.net/ListHelp


Hi Andrew,

phew, I finally made the time to read though all the backlog regarding
the assistant.
Currently it is had for me to find the time to test so here are only a
few thoughts.

Firstly I think it is great that Erpiu showing a lot of interest in the
assistant :-)

so RE first issue
As you might remember when we started the translations you said it
yourself that you are not 100% satisfied with the use of 'their' in the
assistant. I had trouble myself finding a suitable German translation.

Regarding the use of different terms for the authentication two things
come to my mind.
A) double meanings and different names for the same thing should be
avoided/omitted
B) I understand and agree with your concern regarding the level of the
user and how they have different expectations

The first thing I thought was to replace everything by 'identification
key'. For would have the two required key words 'identification' and
'key'. A pro reads the 'key' and draws the conclusion to SSH/PGP keys. A
novice has the 'identification' which he can associate with a pass or a
tag, a swipe card - from there on we have to hope that the novice user
will draw the right conclusions...

After reading on I realised that the dates need to be addressed.

Here comes where the documentation is required because at this stage I
think a 'helper' will know the software to some extent, he will know the
documentation or at least where to find it.

From my experience out of the test I did with other persons - the other
side on the phone is rather relying on what I say than on the
instructions by the assistant. Off course your mileage may vary here but
I dare say that we could write "Compare your dates with the dates of the
helper. Same dates mean your connection is secure" in the assistant.
Everything with more detail can be explained in the documentation.

BTW: I suggest we try to use the community documentation part of the
ubuntu wiki... is that possible?


Now back to the 'their' - I have to agree with Erpiu that having only
the word to translate and then later filling it into text stings might
seem good from a 're-use' point of view. 
It is certainly no easy thing to manage from a translation point of
view. As I said earlier I had difficulties finding a good translation
for 'their' which is not always the same.


Another thought was and I have the feeling I asked this already, why are
there not only two dates? I know that more identical dates equal more
likely the right person on the other side but seriously... what is the
chance of getting two random dates right.
If you need to have more security you are most likely not the main
intended user group of the assistant - please correct me if I'm wrong
here :-)


Cheers,

seb

Attachment: signature.asc
Description: This is a digitally signed message part