On Mon, Aug 20, 2012 at 07:08:12PM -0400, Tom Lane wrote:
The only reason I can see for pushing more crypto into core is
if we needed to stop using MD5 for the core password authentication
functionality. While that might come to pass eventually, I am aware of
no evidence whatever that SHAn,
On Mon, Aug 20, 2012 at 5:54 PM, Greg Sabino Mullane g...@turnstep.com wrote:
3) use a purposefully slow hashing function like bcrypt.
but I disagree: I don't like any scheme that encourages use of low
entropy passwords.
Perhaps off-topic, but how to do you figure that?
Yeah -- bcrypt's
On 8/15/12 6:48 AM, Tom Lane wrote:
The argument against moving crypto code into core remains the same as it
was, ie export regulations. I don't see that that situation has changed
at all.
Actually, I believe that it has, based on my experience getting an
export certificate for Sun Postgres
On 08/20/2012 03:10 PM, Josh Berkus wrote:
On 8/15/12 6:48 AM, Tom Lane wrote:
The argument against moving crypto code into core remains the same as it
was, ie export regulations. I don't see that that situation has changed
at all.
Actually, I believe that it has, based on my experience
I don't think US export regulations are the only issue. Some other
countries (mostly the usual suspects) forbid the use of crypto software.
If we build more crypto functions into the core we make it harder to use
Postgres legally in those places.
Again, that sounds like we need an actual
On 08/20/2012 01:21 PM, Josh Berkus wrote:
I don't think US export regulations are the only issue. Some other
countries (mostly the usual suspects) forbid the use of crypto software.
If we build more crypto functions into the core we make it harder to use
Postgres legally in those places.
On 08/20/2012 04:26 PM, Joshua D. Drake wrote:
On 08/20/2012 01:21 PM, Josh Berkus wrote:
I don't think US export regulations are the only issue. Some other
countries (mostly the usual suspects) forbid the use of crypto
software.
If we build more crypto functions into the core we make it
On 08/20/2012 01:33 PM, Andrew Dunstan wrote:
But there is absolutely no evidence that we are making it less useful.
Postgres is designed top be extensible and we've just enhanced that.
pgcrypto makes use of that. If we cen leverage that to make Postgres
available to more people then why would
On 20 August 2012 21:26, Joshua D. Drake j...@commandprompt.com wrote:
On 08/20/2012 01:21 PM, Josh Berkus wrote:
I don't think US export regulations are the only issue. Some other
countries (mostly the usual suspects) forbid the use of crypto software.
If we build more crypto functions
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If the hacker has access to the salt, then it will only slow
him/her down somewhat because the search will be have to be
restarted for each password.
This. Further, anyone using MD5 or SHA* or any hash function for
any serious storage of
Joshua D. Drake j...@commandprompt.com writes:
On 08/20/2012 01:33 PM, Andrew Dunstan wrote:
But there is absolutely no evidence that we are making it less useful.
Postgres is designed top be extensible and we've just enhanced that.
pgcrypto makes use of that. If we cen leverage that to make
On 08/20/2012 07:08 PM, Tom Lane wrote:
Moreover, as Josh just mentioned, anybody who
thinks it might be insufficiently secure for their purposes has got
plenty of alternatives available today (SSL certificates, PAM backed
by whatever-you-want, etc).
Yeah, I think we need to emphasize this
On 08/20/2012 05:12 PM, Andrew Dunstan wrote:
On 08/20/2012 07:08 PM, Tom Lane wrote:
Moreover, as Josh just mentioned, anybody who
thinks it might be insufficiently secure for their purposes has got
plenty of alternatives available today (SSL certificates, PAM backed
by whatever-you-want,
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
There is still open ToDecide here:
1) Status quo - md5() in core, everything else in pgcrypto
2) Start moving other hashes as separate functions into core: eg. sha1()
Problems:
- sha1 will be obsolete
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
There is still open ToDecide here: [snip]
The argument against moving crypto code into core remains the same as it
was, ie export regulations. I don't see that
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
If anybody's concerned about the security of our password storage,
they'd be much better off working on improving the length and randomness
of the salt string
On 08/15/2012 11:22 AM, Joe Conway wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
If anybody's concerned about the security of our password storage,
they'd be much better off working on improving the
On Wed, Aug 15, 2012 at 11:37:04AM -0400, Andrew Dunstan wrote:
On 08/15/2012 11:22 AM, Joe Conway wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
If anybody's concerned about the security of our
On Wed, Aug 15, 2012 at 10:22 AM, Joe Conway m...@joeconway.com wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
If anybody's concerned about the security of our password storage,
they'd be much better
On 08/15/2012 11:48 AM, Bruce Momjian wrote:
On Wed, Aug 15, 2012 at 11:37:04AM -0400, Andrew Dunstan wrote:
On 08/15/2012 11:22 AM, Joe Conway wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
If
On 08/15/2012 08:49 AM, Merlin Moncure wrote:
1) allow use hmac as you suggest (but this forces user to maintain
additional password or some token)
Not really. You would store a token and the HMAC of the token using the
user password on the server side. You would need access to the hash
On Wed, Aug 15, 2012 at 09:18:48AM -0700, Joe Conway wrote:
The final problem as you stated is weak passwords and some kind of
dictionary attack against a stolen set of tokens and HMACs. Didn't we
add a hook some time ago for user provided password checker?
Yes, contrib/passwordcheck:
On Wed, Aug 15, 2012 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian br...@momjian.us wrote:
Is there a TODO here?
There is still open ToDecide here: [snip]
The argument against moving crypto code into core
Is there a TODO here?
---
On Wed, Aug 10, 2011 at 09:43:18PM +0300, Peter Eisentraut wrote:
On ons, 2011-08-10 at 19:29 +0100, Dave Page wrote:
On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, Sep 02, 2011 at 04:27:46PM -0500, Ross J. Reedstrom wrote:
On Fri, Sep 02, 2011 at 02:05:45PM -0500, k...@rice.edu wrote:
On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
Hmm, this thread seems to have
On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
Hmm, this thread seems to have petered out without a conclusion. Just
wanted to comment that there _are_ non-password storage uses for these
digests: I use them in a
On Fri, Sep 02, 2011 at 02:05:45PM -0500, k...@rice.edu wrote:
On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
Hmm, this thread seems to have petered out without a conclusion. Just
wanted to comment that there
On Wed, Aug 31, 2011 at 11:12 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
Hmm, this thread seems to have petered out without a conclusion. Just
wanted to comment that there _are_ non-password storage uses for these
digests: I use them in a context of storing large files in a bytea
column,
On Fri, Aug 12, 2011 at 10:14:58PM +0300, Marko Kreen wrote:
On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... which this approach would create, because digest()
On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... which this approach would create, because digest() isn't restricted
to just those algorithms. I think it'd be
On Aug 12, 2011, at 5:02 AM, Marko Kreen wrote:
My point was that giving such open-ended list of algorithms
was bad idea, but there is no problem keeping old behaviour.
I don't see anything much wrong with sha1(bytea/text) - bytea.
There's no law that says it has to work exactly like md5()
On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... which this approach would create, because digest() isn't restricted
to just those algorithms. I think it'd be
On ons, 2011-08-10 at 14:19 -0400, Tom Lane wrote:
One thing that might be reasonable would be to move the digest()
functions
digest(data text, type text) returns bytea
digest(data bytea, type text) returns bytea
from pgcrypto into core,
... which this approach would create,
On Thu, Aug 11, 2011 at 09:06, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-08-10 at 14:19 -0400, Tom Lane wrote:
One thing that might be reasonable would be to move the digest()
functions
digest(data text, type text) returns bytea
digest(data bytea, type text) returns
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I would like to see whether there is support for adding sha1 and sha2
functions into the core.
I can't get excited about that, but could put up with it as long as
there wasn't scope
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... which this approach would create, because digest() isn't restricted
to just those algorithms. I think it'd be better to just invent two
new functions, which also avoids issues for
On 08/11/2011 10:46 AM, Tom Lane wrote:
Marko Kreenmark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
... which this approach would create, because digest() isn't restricted
to just those algorithms. I think it'd be better to just invent two
new
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto or one of the PLs. We could say that's OK, but then we do
support md5 in
Peter Eisentraut pete...@gmx.net writes:
I would like to see whether there is support for adding sha1 and sha2
functions into the core.
I can't get excited about that, but could put up with it as long as
there wasn't scope creep ...
One thing that might be reasonable would be to move the
On 08/10/2011 02:06 PM, Peter Eisentraut wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto or one of the PLs. We
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan and...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud if we might be trying to hit a moving target
--
Robert Haas
EnterpriseDB:
On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut pete...@gmx.net wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto
On ons, 2011-08-10 at 19:29 +0100, Dave Page wrote:
On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut pete...@gmx.net wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan and...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud if we might be trying to hit a moving
On 10.08.2011 21:45, Peter Eisentraut wrote:
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstanand...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud
On Wed, Aug 10, 2011 at 21:02, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 10.08.2011 21:45, Peter Eisentraut wrote:
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstanand...@dunslane.net
wrote:
It's come up before:
46 matches
Mail list logo
