Password protection

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

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

But then I thought about it, and it is rather complicated.  It's
acceptable to store the passwords in memory (that's what Firefox does),
but it's not acceptable that any Lisp phrase can say
(get-stored-password ...), and then get the password.  That's too
unsafe.

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

Here's how I see it working:

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

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

3) A new C function is added:

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

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

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

This should be as safe as the Firefox model.  That is, if you read
/proc/mem, you can get at the passwords, but it's not trivially
available from the Lisp layer.  Well, unless you set up a loopback
server or a proxy or something, but the same is the case with Firefox.

Am I missing something obvious here?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen