Re: Password protection

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 28 Sep 2010 16:17:57 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I find it sort of puzzling that we have to jump through all these hoops
LMI> to get at credentials.  I mean, Firefox users don't have to set up a gpg
LMI> agent or type their passwords a gazillion times, so why should users?

Look at it the other way: why shouldn't they set up a GPG agent or enter
a passphrase?  (assuming that entering the passphrase more than once is
a bug I plan to fix)

With the Secrets API they don't need even that much (you should really
try it), but there's a baseline of "I am authorized to open a secure
file."  By comparison, Chrome and Firefox store passwords in a format
that's pretty easy to decrypt and only requires reading files (e.g. see
http://www.blogsdna.com/12040/how-to-recover-stored-google-chrome-passwords.htm)

The user can always set up an unencrypted file if he doesn't like
encryption.

So I'd argue that Emacs has, practically speaking, better security
*externally* than Firefox, Chrome, or most other web browsers with a
authinfo.gpg file.  Now from the inside, yes, it's a candy store of
passwords, and that's a concern.  But Doing It Right requires a lot of
infrastructure that Emacs Lisp doesn't have.  And Firefox and Chrome
extensions can get at your passwords too AFAIK.

LMI> So here's my thought:  If there was a C-level function that would slurp
LMI> in your ~/.authinfo.gpg data, and then let you use it, but without
LMI> actually ever letting a Lisp-level function see the passwords --
LMI> wouldn't that be nice?

LMI> Here's how I see it working:

LMI> 1) Gnus calls (authinfo-store-tokens "~/.authinfo.gpg"), and the user is
LMI> (probably) prompted for a password.

LMI> 2) The data is stored in the C layer, probably obfuscated in some way.

LMI> 3) A new C function is added:

LMI> (process-send-auth process "LOGIN larsi %p\n\r"
LMI>                    '((:hosts ("imap.gmail.com"))
LMI>                      (:ports ("imaps" "imap" 443))
LMI>                      (:user ("larsi"))))

LMI> This function would then work just like `process-send-string', only that
LMI> it roots out the first matching password from the auth info first, and
LMI> expand the string sent.

LMI> That way the Lisp application layer will never actually see the
LMI> password, but it will be able to control what's otherwise being sent,
LMI> and what credentials to use in a flexible manner.

You're basically describing the Secrets API, which does this over D-Bus,
allows saving a password, and has many other features.  So we could have
(auth-source-upload-secrets "authinfo.gpg") to do (1) differentially or
as an overwrite and then (2) and (3) would Just Work persistently.

Ted