Thread: How passwords can be crypted in postgres?
Hello, I order to escape from .htaccess, I want to save user passwords in my database. However, passwords appear clear in the database. How passwords can be crypted in the database? I use PHP 3.0.16, Cobalt Raq3i. Thanks
I usually just run 'crypt()' on the clear text before storing it to the
backend ...
On Fri, 22 Dec 2000 ouldm@linux-at-business.com wrote:
> Hello,
>
> I order to escape from .htaccess, I want to save user passwords in my
> database.
> However, passwords appear clear in the database.
> How passwords can be crypted in the database?
>
> I use PHP 3.0.16, Cobalt Raq3i.
>
>
> Thanks
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From: <ouldm@linux-at-business.com>
> I order to escape from .htaccess, I want to save user passwords in my
> database.
> However, passwords appear clear in the database.
> How passwords can be crypted in the database?
>
> I use PHP 3.0.16, Cobalt Raq3i.
Hmmm.... linux users that haven't heard of freshmeat.net? : )
Typing in "php md5" at freshmeat gives:
http://freshmeat.net/projects/hcemd5/?highlight=php+md5
Which will allow you to encrypt/decrypt as you desire, but I'm sure there
are a hundred other ways to do the encryption, depending on just how much
strength you need.
steve
> I usually just run 'crypt()' on the clear text before storing it to the > backend ... Isn't this just as bad? If you store the encrypted password, that doesn't help you in the slightest in this case, because if you can breach the list of encrypted passwords, you still know what you need to send as the "password" from the front end to let you into the database. Unless I am missing something here, doing this doesn't make any difference... Not for someone serious about breaching security, anyway... Regards. Gordan
> [...] > Isn't this just as bad? If you store the encrypted password, that doesn't > help you in the slightest in this case, because if you can breach the list > of encrypted passwords, you still know what you need to send as the > "password" from the front end to let you into the database. > [...] If you encrypt the input from the frontend as well and compare the encrypted strings it will not help you to look into the list of encrypted passwords ... or am I wrong? Regards, Jens Hartwig ============================================= Jens Hartwig --------------------------------------------- debis Systemhaus GEI mbH 10875 Berlin Tel. : +49 (0)30 2554-3282 Fax : +49 (0)30 2554-3187 Mobil : +49 (0)170 167-2648 E-Mail : jhartwig@debis.com =============================================
> > [...] > > Isn't this just as bad? If you store the encrypted password, that doesn't > > help you in the slightest in this case, because if you can breach the list > > of encrypted passwords, you still know what you need to send as the > > "password" from the front end to let you into the database. > > [...] > > If you encrypt the input from the frontend as well and compare the > encrypted strings it will not help you to look into the list of > encrypted passwords ... or am I wrong? What problem are you trying to defeat? If you are worried about "sniffing" passwords from the traveling packets, then regardless of whether the password field carries a plain text password or scrambled garbage, if you know where the password field is, you can sniff it. If you are simply using this for authentication, then it doesn't matter whether the password is encrypted or not. You are still, effectively, transmitting a "password string" that is used for authentication. The security of passwords, encrypted or otherwise is purely reliant on the security of your database server that stores the data. Does that make sense? Regards. Gordan
Jens Hartwig wrote: > > > [...] > > Isn't this just as bad? If you store the encrypted password, that doesn't > > help you in the slightest in this case, because if you can breach the list > > of encrypted passwords, you still know what you need to send as the > > "password" from the front end to let you into the database. > > [...] > > If you encrypt the input from the frontend as well and compare the > encrypted strings it will not help you to look into the list of > encrypted passwords ... or am I wrong? Slightly wrong -- you need to fetch the salt from the database first. But even so, if you then transmit this ENCRYPTED password, it can be sniffed, and the results of that sniff are all that are needed to access the system. -- Karl DeBisschop kdebisschop@alert.infoplease.com Learning Network/Information Please http://www.infoplease.com Netsaint Plugin Developer kdebisschop@users.sourceforge.net
> If you encrypt the input from the frontend as well and compare the > encrypted strings it will not help you to look into the list of > encrypted passwords ... or am I wrong? If you encrypt the input from the frontend, then someone who had the encrypted passwords and could hack into the front end would be able to control the situation. If someone could hack into the backend and change encrypted passwords, he would have control. Really, we're talking about shared secrets here, and if the secrecy of the shared secret is violated, there's nothing you can do. Public key would be better because you don't have to worry about secrecy, only about it never changing. You could achieve this with some kind of physical medium, like writing private keys to a write-once medium of some kind. Btw, speaking encrypting, I HOPE a future version of PG will have SHA1 in addition to MD5. No one should be using MD5 anymore.
Gordan Bobic wrote: > > > > [...] > > > Isn't this just as bad? If you store the encrypted password, that > doesn't > > > help you in the slightest in this case, because if you can breach the > list > > > of encrypted passwords, you still know what you need to send as the > > > "password" from the front end to let you into the database. > > > [...] > > > > If you encrypt the input from the frontend as well and compare the > > encrypted strings it will not help you to look into the list of > > encrypted passwords ... or am I wrong? > > What problem are you trying to defeat? If you are worried about "sniffing" > passwords from the traveling packets, then regardless of whether the > password field carries a plain text password or scrambled garbage, if you > know where the password field is, you can sniff it. If you are simply using > this for authentication, then it doesn't matter whether the password is > encrypted or not. You are still, effectively, transmitting a "password > string" that is used for authentication. > > The security of passwords, encrypted or otherwise is purely reliant on the > security of your database server that stores the data. > > Does that make sense? Here's a crypted password: 00xNyXeahk4NU. I crypted it in perl as crypt(<guessme>, salt). So what is <guessme>? The point of a one way hash is that it's, well, one way. Pretty much the only way you're going to figure out what password that encrypted string corresponds to is to brute force it. Considering that I crypted a fairly long random string, that could take you a while. A really long while, unless you've got a budget orders of magnitude larger than most people. If you know the password, and you want to check whether it's correct, you just crypt it and compare the strings. Very simple. There are different one way hash functions you might use: md5, crypt, sha, etc. Until the advent of shadow password files, which help defeat brute force attacks of the type I just mentioned, the /etc/password file has been readable by everyone. It really doesn't matter that much if people know the crypted string. They still won't be able to authenticate themselves until they know the real password. So the problem you're trying to defeat by crypting your passwords is the problem of someone reading your password file knowing all of your passwords. Now if you're dumb enough to send cleartext passwords unencrypted over a public network, you need some schooling. And of course any programs doing authentication need to be secure. But that's a different problem altogether. -Ron-
> Here's a crypted password: 00xNyXeahk4NU. I crypted it in perl as > crypt(<guessme>, salt). So what is <guessme>? > > The point of a one way hash is that it's, well, one way. Pretty much > the only way you're going to figure out what password that encrypted > string corresponds to is to brute force it. Considering that I crypted > a fairly long random string, that could take you a while. A really long > while, unless you've got a budget orders of magnitude larger than most > people. [snip] > Until the advent of shadow password files, which help defeat brute force > attacks of the type I just mentioned, the /etc/password file has been > readable by everyone. It really doesn't matter that much if people know > the crypted string. They still won't be able to authenticate themselves > until they know the real password. > > So the problem you're trying to defeat by crypting your passwords is the > problem of someone reading your password file knowing all of your > passwords. > > Now if you're dumb enough to send cleartext passwords unencrypted over a > public network, you need some schooling. And of course any programs > doing authentication need to be secure. But that's a different problem > altogether. I was referring to a different aspect of security. I was referring to preventing more of a "man-in-the-middle" type of attack. If you have a packet sniffer somewhere between the client and the server, then someone could read your packet containing the encrypted password and use it to authenticate to the server, without knowing or caring what the real password is. If you can send the encrypted password to the server that matches, you're in. One way to secure this sort of setup is by using RSA-type algorythm where both client and server get to share a secret without actually transmitting any part of the actual key. This coupled with some form of authentication that would eliminate the man-in-the-middle attack (which would make that system voulnerable as well, because if someone is running a proxy in between you, they would also potentially know the shared secret) should bolt the system down completely. One obvious way to work around this all is to use public key cryptography such as PGP, which would remain secure as long as the private keys remain secure. But, the level of security required largely depends on what you are doing, and what sort of attack you want to protect yourself against... Regards. Gordan
Hello All, It seems to me that a solution for this specific problem (Man-in-the-middle) can be found via SSH Tunneling...;-) Using OpenSSH of course...;-) If you are using (redhat) linux, I believe there is a great book online found at http://www.openna.com called Securing and Optimizing Redhat Linux. There are a bunch of other ways that you can do... But as for the original thread... I think you can encrypt passwords in postgres...;-) But what do I know..;-) > I was referring to a different aspect of security. I was referring to > preventing more of a "man-in-the-middle" type of attack. If you have a > packet sniffer somewhere between the client and the server, then someone > could read your packet containing the encrypted password and use it to > authenticate to the server, without knowing or caring what the real > password is. If you can send the encrypted password to the server that > matches, you're in. > > One way to secure this sort of setup is by using RSA-type algorythm where > both client and server get to share a secret without actually transmitting > any part of the actual key. This coupled with some form of authentication > that would eliminate the man-in-the-middle attack (which would make that > system voulnerable as well, because if someone is running a proxy in > between you, they would also potentially know the shared secret) should > bolt the system down completely. One obvious way to work around this all is > to use public key cryptography such as PGP, which would remain secure as > long as the private keys remain secure. > > But, the level of security required largely depends on what you are doing, > and what sort of attack you want to protect yourself against... > > Regards. > > Gordan -- /) John Clark Naldoza y Lopez (\ / ) Software Design Engineer II ( \ _( (_ _ Web-Application Development _) )_ (((\ \> /_> Cable Modem Network Management System <_\ </ /))) (\\\\ \_/ / NEC Telecom Software Phils., Inc. \ \_/ ////) \ / \ / \ _/ phone: (+63 32) 233-9142 loc. 3112 \_ / / / cellphone: (+63 919) 813-6274 \ \ / / email: njclark@ntsp.nec.co.jp \ \
Gordan Bobic wrote: > > > Here's a crypted password: 00xNyXeahk4NU. I crypted it in perl as > > crypt(<guessme>, salt). So what is <guessme>? > > > > The point of a one way hash is that it's, well, one way. Pretty much > > the only way you're going to figure out what password that encrypted > > string corresponds to is to brute force it. Considering that I crypted > > a fairly long random string, that could take you a while. A really long > > while, unless you've got a budget orders of magnitude larger than most > > people. > > [snip] > > > Until the advent of shadow password files, which help defeat brute force > > attacks of the type I just mentioned, the /etc/password file has been > > readable by everyone. It really doesn't matter that much if people know > > the crypted string. They still won't be able to authenticate themselves > > until they know the real password. > > > > So the problem you're trying to defeat by crypting your passwords is the > > problem of someone reading your password file knowing all of your > > passwords. > > > > Now if you're dumb enough to send cleartext passwords unencrypted over a > > public network, you need some schooling. And of course any programs > > doing authentication need to be secure. But that's a different problem > > altogether. > > I was referring to a different aspect of security. I was referring to > preventing more of a "man-in-the-middle" type of attack. If you have a > packet sniffer somewhere between the client and the server, then someone > could read your packet containing the encrypted password and use it to > authenticate to the server, without knowing or caring what the real > password is. If you can send the encrypted password to the server that > matches, you're in. How so? The server is going to take the string you send it, and one-way hash it. If you send it the hash value, it will hash that. Unless that happens to hash to itself, which is exceedingly unlikely, you will not be authenticated. What kind of system are you talking about? -Ron-
On Thu, Jan 04, 2001 at 10:53:12PM -0500, some SMTP stream spewed forth:
> Gordan Bobic wrote:
> >
> > > Here's a crypted password: 00xNyXeahk4NU. I crypted it in perl as
> > > crypt(<guessme>, salt). So what is <guessme>?
> > >
> > > The point of a one way hash is that it's, well, one way. Pretty much
> > > the only way you're going to figure out what password that encrypted
> > > string corresponds to is to brute force it. Considering that I crypted
> > > a fairly long random string, that could take you a while. A really long
> > > while, unless you've got a budget orders of magnitude larger than most
> > > people.
> >
> > [snip]
> >
> > > Until the advent of shadow password files, which help defeat brute force
> > > attacks of the type I just mentioned, the /etc/password file has been
> > > readable by everyone. It really doesn't matter that much if people know
> > > the crypted string. They still won't be able to authenticate themselves
> > > until they know the real password.
> > >
> > > So the problem you're trying to defeat by crypting your passwords is the
> > > problem of someone reading your password file knowing all of your
> > > passwords.
> > >
> > > Now if you're dumb enough to send cleartext passwords unencrypted over a
> > > public network, you need some schooling. And of course any programs
> > > doing authentication need to be secure. But that's a different problem
> > > altogether.
> >
> > I was referring to a different aspect of security. I was referring to
> > preventing more of a "man-in-the-middle" type of attack. If you have a
> > packet sniffer somewhere between the client and the server, then someone
> > could read your packet containing the encrypted password and use it to
> > authenticate to the server, without knowing or caring what the real
> > password is. If you can send the encrypted password to the server that
> > matches, you're in.
>
> How so? The server is going to take the string you send it, and one-way
> hash it. If you send it the hash value, it will hash that. Unless that
> happens to hash to itself, which is exceedingly unlikely, you will not
> be authenticated.
>
> What kind of system are you talking about?
It seems to me that the situation he describes would be one in which
the frontend recieves an auth key ("password" or whatever) and then
compares the hash of it to a value in the database. A similar situation
would arise if the frontend merely passed the auth key to the database
and the database hashed it and compared the hash to a stored hash.
It is really just a big mess.
Recieving a key, hashing it, and having the database hash the hash
might actually work reasonably well. But not really.
By hashing it, you increase the number of members in the set of
keys that the database would consider "valid" (or that would be
such that would allow access) provided that the database hashes the hash.
Otherwise, you are back in the same f'mess. Which you pretty much are
anyway, as the "key" simply becomes the hash of the "real" "password" if
you bypass the frontend. A someone else mentioned, a shared secret setup
would go far to avoiding a problem like this. But, if you cannot trust
your connection for a shared secret setup, you have a bigger problem. ;-)
Have fun.
gh
>
> -Ron-
Ron Peterson wrote: > > I was referring to a different aspect of security. I was referring to > > preventing more of a "man-in-the-middle" type of attack. If you have a > > packet sniffer somewhere between the client and the server, then someone > > could read your packet containing the encrypted password and use it to > > authenticate to the server, without knowing or caring what the real > > password is. If you can send the encrypted password to the server that > > matches, you're in. > > How so? The server is going to take the string you send it, and one-way > hash it. If you send it the hash value, it will hash that. Unless that > happens to hash to itself, which is exceedingly unlikely, you will not > be authenticated. > > What kind of system are you talking about? Man in the middle attack, _ultra-simplified_: User A uses a voice-print, saying: "my voice is my password" to enter. Cracker B tape-records user A saying the above phrase, and then plays it back to hack in. On a lan: User A logs in and sends a password, hashed as "drowssap". Cracker B sniffs it, logs in, and sends a password, hashed as "drowssap". or User A logs in and sends a password, "password". Cracker B sniffs it, logs in, and sends a password, "password". The "man in the middle" attack has many variants, but basically it centers around capturing the credentialing process in such a way that having the *actual* credentials are irrelevant. -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.
GH wrote:
>
> It seems to me that the situation he describes would be one in which
> the frontend recieves an auth key ("password" or whatever) and then
> compares the hash of it to a value in the database. A similar situation
> would arise if the frontend merely passed the auth key to the database
> and the database hashed it and compared the hash to a stored hash.
If someone creates a front-end authentication mechanism of the type you
describe, they're in for a world of hurt. The second scenario you
describe is very much how authentication is typically done, right? Of
course there are things you need to do to make the process secure, like
wiping all trace of the unhashed password from memory as soon as
possible, controlling access permissions, etc. But again, that's a
different subject.
There are many aspects to security. The problem with this discussion is
that all of those different aspects are being mushed together into one
big jumble.
The original question was whether it is wise to store passwords in plain
text, or to store their hashed values. The answer is it is better to
store the hashed values. PGP encryption is also more secure, but you
face the additional risk of someone obtaining the meta-password. The
advantage is that you can always rehash the password if you need to.
Like if you update an LDAP user directory with md5 hashed passwords
rather than crypted passwords, for example. (i.e. - don't assume that
just because passwords are being stored in PostgreSQL, that
authentication is being done against PostgreSQL. It might just be a
repository used for distribution.)
Taking care of other security aspects, like writing a program to do
authentication in a secure manner, or encrypting your network traffic,
is another topic altogether.
> Have fun.
Always ;)
-Ron-