Skip site navigation (1) Skip section navigation (2)

Re: Spoofing as the postmaster

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spoofing as the postmaster
Date: 2007-12-28 22:39:51
Message-ID: 47757B37.9040609@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander wrote:
> Mark Mielke wrote:
>   
>>
>> I have done this for my own application before. Although the client and
>> server use standard TLS 1.0 to speak to each other with a required
>> authentication of RSA 1024-bit and a required encryption of AES 128-bit,
>> it still requires that passwords sent from the client to the server are
>> RSA encrypted using the server public certificate, making it impossible
>> for anybody except for the legitimate server to see the password. One
>> benefit of this is that the password itself can be '\0'd out as soon as
>> we have RSA encrypted it, and things like a core dump of the client have
>> a lower chance of including the password in plain text.
>>     
>
> Why are you even using a password in this case, and not just key-based
> auth? Wouldn't that be even easier and more secure?
>   

Users of this product don't have keys - they have passwords. The 
username/password is for per-user authentication. The username defines 
the access level. Many users will use the same client. The client does 
have its own private RSA key and public certificate, however, this 
grants entry to the system. Password login is still required by the 
users of the client.

>> At what point does prudence become paranoia? I don't know. In my case, I
>> felt 128-bit encryption was insufficient for protecting the passwords in
>> my application. 256-bit encryption would have been sufficient, but that
>> cannot yet be safely exported from the US to the countries I required.
>>     
> How do you protect the certificate store on the client? Or the binary
> that ends up prompting for the password on the client
The certificate on the client grants access to the system. It does not 
grant access to the resources on the system. Two-level authentication 
with mandatory server authentication. You see similar things in physical 
security instances. A security badge lets you in the door - but you 
still need to login to the computer once you get in.

As for protecting the binary that prompts for a password on the client - 
I didn't bother with this, although Java does allow for signed jar files 
that would allow the user to be assured that the client is legitimate. 
There are always loops though, just because the client is legitimate 
doesn't mean that the keyboard is, and so on. You end up putting in 
enough effort to mitigate the risk. The risk always exists, but through 
clever, cryptographic, or obfuscatory measures, the risk can be greatly 
reduced.

Cheers,
mark

-- 
Mark Mielke <mark(at)mielke(dot)cc>

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-12-28 22:56:56
Subject: Re: minimal update
Previous:From: Magnus HaganderDate: 2007-12-28 22:30:08
Subject: Re: Spoofing as the postmaster

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group