Hi!
Sorry to be late to the party. I still haven't seen UX concerns fully
addressed, and I think we should not create a specification that will
make the life of our users harder if we can avoid it.
s7r:
> George Kadianakis wrote:
> > I have a more mature torspec branch now for your eyes and only. Please
> > see branch `prop224_client_auth_4` in my torspec repo:
> > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
> >
> > The changes are based on the feedback and discussion on this thread.
>
> I would like to state, since I seen it in older posts on this thread,
> that I dislike the idea of generating at client side low entropy ed25519
> key pairs based on simple passwords. It may sound simple and good from
> UX point of view, but we are decreasing the security of a very secure
> auth scheme with it and enabling an over-the-hand practice that keys
> come from client to HS and not vice-versa.
I hope we can find a balance between “a very secure auth scheme” that
will be too cumbersome to use for most users and “a secure and usable
auth scheme”.
I've been hoping we could get a nice UI in Tor Browser to access
authenticated onion services for a while now (#8000). The difficult part
UX-wise is that there is no way to differentiate between an onion
service that is either non-existant, temporary unavailable or
authenticated. (But it's good for security, so let's keep things that
way.)
How are users expected to give enter the private key in Tor Browser?
Does the key have to be saved on disk? What should I have to do to
browse an authenticated onion service when running under Tails without
persistence enabled?
I don't see how to streamline support for an amnesic system if I have to
generate a unique keypair that I need to give to the onion service
owner beforehand.
Should we draw inspiration from miniLock?
https://minilock.io/files/HOPEX.pdf (see slide 35)
If I try to think of my experience as an admin, I see several cases
where it would be much easier to give authentication token to users
myself. User story:
Elena has set up an Etherpad instance on her private server. She
generates a handful of access codes before going to meet the newly
formed copwatch chapter. After the end of the meeting, she can give
out a piece of paper to all attendees so they can access the minutes
and write up reports together in the future.
You really don't want to have all attendees bring their computer or
require them to meet with Elena at a later time.
Hope that helps,
--
Lunar <lunar@xxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev