-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
That line of argument could be used to justify putting anything and
everything in core. I think that our extensible architecture is an
important feature and one we should not hesitate to use to the fullest.
I agree, but part of the problem
Greg Sabino Mullane wrote:
4) We're also encouraging the use of md5() by making it the only option.
Yes, we can talk about why people *shouldn't* use it for this purpose
or that, but they will.
There is always the Java route - internal classes have package-scope
constructors to
Mark Mielke wrote:
This presumes that better hashes truly exist. It is basic math to show
that all hashes will include collisions. Ignoring the possibility that
one hash has theoretical better distribution for real documents, the
real benefit of SHA-1 over MD5, is that it has more bits. The
Svenne Krap wrote:
Mark Mielke wrote:
This presumes that better hashes truly exist. It is basic math to
show that all hashes will include collisions. Ignoring the
possibility that one hash has theoretical better distribution for
real documents, the real benefit of SHA-1 over MD5, is that it
On Thu, Apr 03, 2008 at 06:14:17PM +0200, Svenne Krap wrote:
Hashes are an absolute minimum for keeping passwords stored somehat
safely in a database.
More two or even three different hashes with different collion-points
will strongly increase the security.
Not only that, but they also
Mark Mielke wrote:
More two or even three different hashes with different collion-points
will strongly increase the security.
No it doesn't unless you are thinking about a security through
obscurity argument.
It is really the same argument on all your questions
If I have a simple table
Svenne Krap wrote:
If I have a simple table now
ID serial
Username varchar
Password varchar
I currently save only md5(id || username || 'password')* into
password, if I had access to sha1 (for example) i would add another
password column so, having for example
ID serial
Username
Mark Mielke wrote:
Svenne Krap wrote:
Mark Mielke wrote:
Svenne Krap wrote:
More two or even three different hashes with different
collion-points will strongly increase the security.
No it doesn't unless you are thinking about a security through
obscurity argument
Your logic is invalid - the
On Thu, Apr 03, 2008 at 07:07:56PM +0200, Svenne Krap wrote:
I currently save only md5(id || username || 'password')* into password,
if I had access to sha1 (for example) i would add another password
column so, having for example
ID serial
Username varchar
Password_md5 varchar
Svenne Krap wrote:
I would still prefer two hash functions as they do add a better
safeguard towards collisions (the gentoo distribtion actually hashes
the files by three different algorithms SHA1, SHA256 and RMD160) - i
would be inclined to use three hashes too, if they were instantly
Mark Mielke wrote:
In any case, this is all irrelevant, because md5 passwords are still
very useful, and the argument that more = better is a never ending
infinite resource trap. More is not better. Better is better. If you can
prove md5 is insufficient for PostgreSQL passwords, the correct
Heikki Linnakangas wrote:
Mark Mielke wrote:
One must also remember that if you use two hashes, if *either* one of
them is broken in the future so that you can reconstruct the password
from the hash, you're screwed.
That is quite a good argument actually :)
--
Sent via pgsql-hackers mailing
Sam Mason wrote:
Are you a cryptanalyst and are you sure that this doesn't actually make
things worse? I'm sure it gives you a warm fuzzy feeling that it's
*got* to be better, but unless someone has done some hard maths I'm not
sure how you can be so sure.
No sadly I am no cryptoanalyst.
Sam Mason wrote:
On Thu, Apr 03, 2008 at 07:07:56PM +0200, Svenne Krap wrote:
ID serial
Username varchar
Password_md5 varchar
Password_sha1 varchar
...
Why not just use SHA-512, you get many more quality bits that way.
Or if he just wanted to use builtin tools and reduce accidental
On Fri, Apr 04, 2008 at 12:06:03AM +0200, Svenne Krap wrote:
Sam Mason wrote:
Are you a cryptanalyst and are you sure that this doesn't actually make
things worse? I'm sure it gives you a warm fuzzy feeling that it's
*got* to be better, but unless someone has done some hard maths I'm not
On Thu, Apr 03, 2008 at 04:42:47PM -0700, Ron Mayer wrote:
Sam Mason wrote:
On Thu, Apr 03, 2008 at 07:07:56PM +0200, Svenne Krap wrote:
ID serial
Username varchar
Password_md5 varchar
Password_sha1 varchar
...
Why not just use SHA-512, you get many more quality bits that way.
Or if
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
There isn't enough agreement to move some things from pgcrypto
to the core so this thread is being removed from the patch queue.
I don't agree that we should just close discussion. Nobody seems happy
with the status quo, which is that we
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I don't agree that we should just close discussion. Nobody seems happy
with the status quo, which is that we provide md5 but not sha1,
There may be a few people who are unhappy, but the above claim seems
vastly overblown. md5 is sufficient for the
On Wed, Apr 02, 2008 at 01:07:01PM -, Greg Sabino Mullane wrote:
There isn't enough agreement to move some things from pgcrypto to
the core so this thread is being removed from the patch queue.
I don't agree that we should just close discussion. Nobody seems
happy with the status
David Fetter [EMAIL PROTECTED] writes:
Just exactly which encryption legislation are we talking about here?
I know there was some fuss about this issue back in the early 1990s,
but that was many, many law changes and court cases ago, world-wide.
It's far from clear to me that there's any
On Wed, Apr 02, 2008 at 12:27:15PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Just exactly which encryption legislation are we talking about
here?
I know there was some fuss about this issue back in the early
1990s, but that was many, many law changes and court cases
tier for password
hashing.
Would replacing md5 with SHA1 in core involve much work?
Sanjay Sharma To: [EMAIL PROTECTED] CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3 Date: Wed, 2 Apr 2008
11:38:31 -0400 From: [EMAIL PROTECTED] Greg Sabino Mullane
David Fetter wrote:
On Wed, Apr 02, 2008 at 12:27:15PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Just exactly which encryption legislation are we talking about
here?
I know there was some fuss about this issue back in the early
1990s, but that was many, many
David Fetter [EMAIL PROTECTED] writes:
Re: compulsively attempting to comply with every law everywhere, let's
recall that a certain Search! engine company managed to get itself in
a morally pretty reprehensible spot by following the laws of an
oppressive regime. We needn't do the same.
We
On Wed, Apr 02, 2008 at 12:49:38PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Re: compulsively attempting to comply with every law everywhere,
let's recall that a certain Search! engine company managed to get
itself in a morally pretty reprehensible spot by following the
David Fetter [EMAIL PROTECTED] writes:
That cat is already out of the bag with every Linux distribution.
There's just no point in our going three sides around the square in
order to have someone, somewhere claim that our tarball isn't
violating their law.
[shrug...] It's not exactly terribly
sanjay sharma [EMAIL PROTECTED] writes:
md5 is not being recommended anywhere because it contains hash
collision.
For the purposes we are using it for, that's just about 100% irrelevant.
Would replacing md5 with SHA1 in core involve much work?
Yes, it would be a tremendous problem, because
Am Mittwoch, 2. April 2008 schrieb David Fetter:
That cat is already out of the bag with every Linux distribution.
There are other operating systems besides Linux.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
sanjay sharma wrote:
Hi Tom,
md5 is not being recommended anywhere because it contains hash
collision. Therefore either it should be replaced with SHA1 or any
other good hash algorithm or taken out of core completely. md5 in core
is worthless now.I am not using it in my application. I am
On Wed, Apr 02, 2008 at 07:16:53PM +0200, Peter Eisentraut wrote:
Am Mittwoch, 2. April 2008 schrieb David Fetter:
That cat is already out of the bag with every Linux distribution.
There are other operating systems besides Linux.
And the cat's out of the bag there, too. Have you tried to
Am Mittwoch, 2. April 2008 schrieb sanjay sharma:
md5 is not being recommended anywhere because it contains hash collision.
Therefore either it should be replaced with SHA1 or any other good hash
algorithm or taken out of core completely. md5 in core is worthless now.I
am not using it in my
David Fetter wrote:
And the cat's out of the bag there, too. Have you tried to get a
system that doesn't include strong crypto running any time recently?
Well yes, I have recently been involved in a large deployment of such systems.
The details are a bit too involved for this thread, but the
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I don't agree that we should just close discussion. Nobody seems
happy with the status quo, which is that we provide md5 but not
sha1,
There may be a few people who are unhappy, but the above claim seems
vastly overblown.
Was that really the conclusion? My memory of this thread showed that
most people who actually deal with hashes and cryptography *wanted* a
SHA based hash in core (because our users ask for it!) and the only
disagreement was in *what* should be included.
//Magnus
Bruce Momjian wrote:
There
Magnus Hagander wrote:
I think that claim is completely incorrect.
A lot of people use the md5() function in PostgreSQL today to hash
the passwords for the users of whatever webbapp they are running. It
only uses one account to connect to PostgreSQL and handles the rest of
the auth elsewhere in
Magnus Hagander [EMAIL PROTECTED] writes:
... These users would like to have sha1
(and/or other securer hashes). And they would like it in -core, because
their hosting company don't install the contrib modules.
That line of argument could be used to justify putting anything and
everything in
Tom Lane wrote:
There is clearly work that could/should be done to improve it, such
as having better system support for packages or modules or whatever
you want to call them; and maybe we also need some marketing-type
work to encourage people such as hosting companies to allow access
to
On Wed, Apr 02, 2008 at 05:09:14PM -0400, Andrew Dunstan wrote:
Standard Modules. Maybe we could rename the directory modules. IIRC
This seems like an easy and practical answer.
A
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Magnus Hagander wrote:
Was that really the conclusion? My memory of this thread showed that
most people who actually deal with hashes and cryptography *wanted* a
SHA based hash in core (because our users ask for it!) and the only
disagreement was in *what* should be included.
Sorry if it
There isn't enough agreement to move some things from pgcrypto to the
core so this thread is being removed from the patch queue.
---
Bruce Momjian wrote:
I am not thrilled about moving _some_ of pgcrypto into the backend
On 1/28/08, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I am not thrilled about moving _some_ of pgcrypto into the backend ---
pgcrypto right now seems well designed and if we pull part of it out it
seems it will be less clear than what we have now. Perhaps we just need
to document that
* Bruce Momjian:
I am not thrilled about moving _some_ of pgcrypto into the backend ---
pgcrypto right now seems well designed and if we pull part of it out it
seems it will be less clear than what we have now. Perhaps we just need
to document that md5() isn't for general use and some
I am not thrilled about moving _some_ of pgcrypto into the backend ---
pgcrypto right now seems well designed and if we pull part of it out it
seems it will be less clear than what we have now. Perhaps we just need
to document that md5() isn't for general use and some function in
pgcrypto should
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I am not thrilled about moving _some_ of pgcrypto into the backend ---
pgcrypto right now seems well designed and if we pull part of it out it
seems it will be less clear than what we have now. Perhaps we just need
to document that md5()
On 1/20/08, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
In summary: what would objections be to my writing a sha1() patch?
Well.
If you do start adding hashes to core then _please_ pick a path
that allows having all the standard hashes in advance. That means
both md5 and sha-1, sha2 (4
Florian Weimer [EMAIL PROTECTED] writes:
* David Fetter:
Is there any country with laws so benighted that they restrict secure
hashing algorithms? Right now, there's a contest between SHA1 and
MD5 as to which one gets broken first, and SHA1 appears to be in the
lead. SHAn for n1 could
* Tom Lane:
MD5 is broken in the sense that you can create two or more meaningful
documents with the same hash.
Note that this isn't actually very interesting for the purpose for
which the md5() function was put into core: namely, hashing passwords
before they are stored in pg_authid.
No
On 1/21/08, Florian Weimer [EMAIL PROTECTED] wrote:
BTW, I'd like to see MD5/SHA-1 for BYTEA, not just TEXT, and with a
BYTEA return value. Does pgcrypto provide that?
Yes.
--
marko
---(end of broadcast)---
TIP 4: Have you searched our list
On 1/21/08, Tom Lane [EMAIL PROTECTED] wrote:
MD5 is broken in the sense that you can create two or more meaningful
documents with the same hash.
Note that this isn't actually very interesting for the purpose for
which the md5() function was put into core: namely, hashing passwords
before
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In MySQL I have a function SHA1, which is critical for storing and
authenticating passwords.
It sure would be nice to have this in core. Yeah, there's pgcrypto,
but it's a bit overkill for people who simply want to do a SHA1,
especially
Greg Sabino Mullane wrote:
I also realize that SHA1 is not a great solution these days either,
but I'd at least like to see a discussion on moving Postgres to
somewhere between only has md5() and all pg_crypto functions inside
core, even if it only means a handful of SHA functions. Moving
On Sun, Jan 20, 2008 at 05:24:11PM -, Greg Sabino Mullane wrote:
It sure would be nice to have this in core. Yeah, there's pgcrypto,
but it's a bit overkill for people who simply want to do a SHA1,
especially when they see we already have a md5().
md5() was added with the following
Alvaro Herrera wrote:
Greg Sabino Mullane wrote:
I also realize that SHA1 is not a great solution these days either,
but I'd at least like to see a discussion on moving Postgres to
somewhere between only has md5() and all pg_crypto functions inside
core, even if it only means a handful of SHA
Martijn van Oosterhout wrote:
In summary: what would objections be to my writing a sha1() patch?
There wasn't any discussion about it last time. It does seem a bit
wierd to support one but not the other. It's also interesting to note
that the implementation in the backed is commented with:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
In summary: what would objections be to my writing a sha1() patch?
Mainly that no one else is dissatisfied with the current split between
core and pgcrypto.
The only reason md5() is in core is to support encryption of passwords
in pg_shadow. There
On Sun, Jan 20, 2008 at 01:42:21PM -0500, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
In summary: what would objections be to my writing a sha1() patch?
Mainly that no one else is dissatisfied with the current split
between core and pgcrypto.
The only reason md5() is
* David Fetter:
Is there any country with laws so benighted that they restrict secure
hashing algorithms? Right now, there's a contest between SHA1 and
MD5 as to which one gets broken first, and SHA1 appears to be in the
lead. SHAn for n1 could preempt the awfulness of losing this race.
57 matches
Mail list logo
