Re: Questions about digest authentication (and some other stuff)

[Dan Winship <danw gnome org>]

On 06/06/2013 07:45 PM, Matthew Brush wrote:
> 1) Is there a recommended method/package for handling the actual
> user/password database?

In the case of digest auth, the protocol requires you to have the exact
string output by soup_auth_domain_digest_encode_password(), so the only
two possibilities are (1) store the password in plaintext (which
obviously you don't want to do), and (2) store the output of that
function. You can't store a hashed version of either of them.

So, if you're paranoid about the password database being captured and
brute-forced, then you're actually better off using Basic-over-SSL
rather than Digest, because then you can hash the password however you
want (eg, bcrypt) before storing it.

> Am I being stupid
> and/or paranoid in wanting to take these measures, and if not, could
> someone recommend a way to work around the mentioned issues? I'm
> wondering, if some cracker is already accessing my swap file/partition
> and/or recycled memory, is it pretty much pointless/too-late to be
> worrying about somewhat weakly encoded passwords getting into there?

If you are using Digest auth then the hashed user/realm/password that
you have to store on disk is a password-equivalent. (If a hacker gets
access to it, they can use it to authenticate via Digest auth with, even
if they can't extract the original password from it.) So there's no real
point in protecting it in memory since it's already on disk. If you are
using Basic auth, then the password is going to appear in plaintext in
the HTTP headers, and so is pretty much guaranteed to end up somewhere
in memory outside of your control. So I think there's not much you can
do here.

(I'd accept patches to minimize the total exposure of the password in
that case though.)

> 3) Does libsoup use/have any means of doing key-stretching and/or
> salting?

With Digest auth, there's nothing you can do. With Basic auth, libsoup
never deals with the passwords itself, it just asks "is username 'bob'
password 'fido' ok?", and you can do whatever sort of salting, etc, you
want.

> On a similar vein, does it implement any means of limiting
> denial of service attacks or brute force password cracking attempts or
> is this left to the user to do based on their specific requirements?

The latter.

> 4) Is there any way to get access to the raw socket fd (or GSocket even)
> for a client connection in a way that it can be safely written to
> outside of libsoup?

No. There may eventually be an API that would let you get it in the case
where the connection is going to be closed after the request anyway, but
there's nothing now.

There will also be APIs in the future that will use GOutputStream rather
than the current streaming hacks, but that also doesn't exist yet.

-- Dan