Re: How passwords can be crypted in postgres?
От | Gordan Bobic |
---|---|
Тема | Re: How passwords can be crypted in postgres? |
Дата | |
Msg-id | 008501c07566$06ed41a0$8000000a@localdomain обсуждение исходный текст |
Ответ на | Re: How passwords can be crypted in postgres? ("Gordan Bobic" <gordan@freeuk.com>) |
Список | pgsql-general |
> 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
В списке pgsql-general по дате отправления: