[OTR-users] Pretty-please standardize OTR signature storage, per OS.

Tamme Schichler tammeschichler at googlemail.com
Tue Sep 10 18:50:50 EDT 2013


Am 10.09.2013 23:59, schrieb Daniel Kahn Gillmor:
> On 09/10/2013 05:41 PM, subharo at hushmail.com wrote:
>
>> After thinking through your idea, I think I've found a potential
>> problem that should be pondered.  In Windows, your loopback daemon
>> would work fine, because Windows is not truly Multi-User (in the
>> sense that *you can't multiple human users logging at the same
>> time,* with separate, independent "Sessions").
>
> This is not true.  Even non-server versions of Windows allow you to
> "switch user" such that one user's processes and tasks are running in
> the background already.
>
>> Unix user Alice running your loopback daemon could have her keys
>> read, modified, or deleted by Unix User Bob, who has SSH'ed/X2go'd
>> into that same machine.  An example scenario: University students
>> playing pranks on each other in Unix computer labs with NIS+/NFS
>> network accounts giving them access on all the other UNIX machines.
>
> the monkeysphere validation agent addresses this concern by scanning
> /proc/net/tcp as a connection is made to ensure that the connection is
> being made by a process with the expected uid.  I don't know if there's
> an analogous mechanism on windows.
>
>> I think your idea needs a security mechanism, like say, a master
>> password, before the OTR signatures can be accessed.
>
> If you really can't authenticate the connecting peer some other way,
> there are many non-password mechanisms (e.g. key-based authentication
> based on auto-generated and rotated keys stored in the filesystem that
> are only readable by the user who runs the service) that make more sense
> than exposing the user to yet another password regime.
>
> passwords are terrible.
>
> 	--dkg

I agree.

I just looked at alternatives and it seems that named pipes can have 
security settings that allow only a certain user to access them. They 
should otherwise work like a loopback socket, just with a different 
(better) namespace. I never used them before, so I didn't know about 
this possibility.



More information about the OTR-users mailing list