On 5 March 2015 at 22:39, Aaron Zauner wrote:
> Yep. I confused SRP with PSK ciphersuites here. There're no ciphersuites
> that support PKIX and SRP. Unfortunately there's also only AES-CBC
> (mac-then-encrypt) as a possible option when using SRP.
> https://www.iana.org/assignments/tls-parameters
Hi,
On 5 March 2015 at 19:58, Christoph Berg wrote:
>> That's an excellent thought.. I wasn't aware of this. Unfortunately,
>> I'm not sure that we could make it the default in Debian as it requires
>> server-side certificates be configured and used properly (correct?) but
>> I don't see a reas
Hi,
On 5 March 2015 at 01:25, Stephen Frost wrote:
> I was hoping for an option which would actually improve it, not make it
> the same as another mechanism that already exists..
Ok, so my general advice would definitely still be to use "password"
authentication for unix and TLS sockets. When p
Hi,
On 4 March 2015 at 15:22, Stephen Frost wrote:
> That really just changes it back to the 'password' case though, doesn't
> it? An attacker who can sniff the network would get the response from
> the client and be able to use it in a replay attack just as if it was
> the password.
They can a
Hi,
On 4 March 2015 at 12:33, Stephen Frost wrote:
> * Michael Samuel (m...@miknet.net) wrote:
>> - I don't recommend storing the password in cleartext
>> - I *do* recommend exchanging the password in cleartext over the network
>
> And I will continue to argue that it
ponse protocol to be added to
the heap. If anyone from postgres is interested in putting a
network-compatible fix for password hashing in, feel free to contact
me.
On 4 March 2015 at 12:09, Michael Samuel wrote:
> Hi,
>
> On 4 March 2015 at 12:03, Aaron Zauner wrote:
>>> Uh,
Hi,
On 4 March 2015 at 12:03, Aaron Zauner wrote:
>> Uh, no, using 'password' is far worse, and uniformly so, than using md5.
>> I have no idea why anyone would think it's better to store a cleartext
>> version of your password in the pg_authid data (note that pg_shadow is
>> only a view now, I r
On 20 November 2014 17:55, wrote:
> Use CVE-2014-8990. The scope of this CVE ID includes both:
> 2. denial of service scenarios in which a user with write access
> to a local directory uses special characters to make
> synchronization fail (might have security relevance in some
>
8 matches
Mail list logo
