Re: opaque data types

[Ted Zlatanov]

On Sat,  8 Jun 2013 10:19:34 +0100 (BST) Christopher Schmidt <address@hidden> 
wrote: 

CS> Ted Zlatanov <address@hidden> writes:
CS> Considering we are talking about a regular userspace application
CS> with no distributed components I do not see any advantage at all
CS> by encrypting passwords in memory.  How does interposing a
CS> function to extract passwords from a new inbuild type increase
CS> security at all?
>> 
>> By making it less trivial to extract them.

CS> That is security through obscurity.

I disagree with that statement.  Perhaps we're talking about different
things.  My goal is not to obscure the data but to encrypt it so it's
not trivially extracted.

>> The opaque type makes it possible to change the implementation if
>> better ways are available on a platform, e.g. the Mac OS X keychain or
>> the Secrets API or the W32 keychain.  The fallback mechanism can at
>> least make it a little harder to get someone's passwords.

CS> Storing passwords using different backends does not require in-memory
CS> encryption or a new opaque type.

True.  But my experience with auth-source.el (which in fact provides
these backends) was that it's very hard to make it even a little bit
secure at the Lisp level alone.

CS> How is this new type in combination with custom hard back ends superior
CS> to what auth-info.el is doing already?

It's harder to corrupt, inspect, or intercept the underlying data
transactions from Lisp code if they are at the C level.

You don't have to depend on external utilities if you call the libraries
directly.  OTOH you have to worry about the API changing...

The data you pass back and forth is not visible to every Lisp function.

CS> Who's your attacker anyway?
>> 
>> Do we have to do risk assessments too?

CS> I do not understand that question.

I am saying I hope I don't have to invent an attacker to justify my
proposal.  Look at it this way: do you feel Emacs provides good enough
security?  I don't, based on what I know about Emacs Lisp and the
underlying C code.  When it's not possible to write 15 lines of Lisp to
grab my passwords out of memory, I'll be less worried.

Ted