Thread: Password requirement in windows installer
Why does the windows installer require a password for the superuser account, since it's perfectly legitimate not to have a password on that account? I could see perhaps producing a warning, but making this a hard requirement seems like overkill. -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Decibel! wrote: > Why does the windows installer require a password for the superuser > account, since it's perfectly legitimate not to have a password on that > account? I could see perhaps producing a warning, but making this a hard > requirement seems like overkill. Security out of the box. There are few, if any good reasons not to have a password on the account, and if you really want to remove it, you can do so in psql or pgAdmin. Regards, Dave.
On Fri, Aug 31, 2007 at 09:02:49AM +0100, Dave Page wrote: > Decibel! wrote: > > Why does the windows installer require a password for the superuser > > account, since it's perfectly legitimate not to have a password on that > > account? I could see perhaps producing a warning, but making this a hard > > requirement seems like overkill. > > Security out of the box. There are few, if any good reasons not to have > a password on the account, and if you really want to remove it, you can > do so in psql or pgAdmin. Is there something insecure about using ident sameuser for localhost authentication on Windows? -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Decibel! wrote: > On Fri, Aug 31, 2007 at 09:02:49AM +0100, Dave Page wrote: >> Decibel! wrote: >>> Why does the windows installer require a password for the superuser >>> account, since it's perfectly legitimate not to have a password on that >>> account? I could see perhaps producing a warning, but making this a hard >>> requirement seems like overkill. >> Security out of the box. There are few, if any good reasons not to have >> a password on the account, and if you really want to remove it, you can >> do so in psql or pgAdmin. > > Is there something insecure about using ident sameuser for localhost > authentication on Windows? Windows doesn't have ident (though there are 3rd party products). Regards Dave
Decibel! wrote: > Is there something insecure about using ident sameuser for localhost > authentication on Windows? > FWIW, I never advise people to use ident auth for postgres except on local (a.k.a. Unix domain socket) connections, which don't exist on Windows. cheers andrew
On Fri, Aug 31, 2007 at 12:37:16PM -0400, Andrew Dunstan wrote: > > > Decibel! wrote: > >Is there something insecure about using ident sameuser for localhost > >authentication on Windows? > > > > FWIW, I never advise people to use ident auth for postgres except on > local (a.k.a. Unix domain socket) connections, which don't exist on Windows. Is it easy to spoof where an incoming connection request is coming from? Is there something else that makes ident on 127.0.0.1/32 insecure? -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Fri, Aug 31, 2007 at 12:30:02PM -0500, Decibel! wrote: > > Is it easy to spoof where an incoming connection request is coming from? > Is there something else that makes ident on 127.0.0.1/32 insecure? It shouldn't be easy. Ident uses TCP, which is rather harder to spoof. If someone can originate spoofed TCP packets from 127.0.0.1, you gots bigger problems than them being able to lie about the identity of a user. A -- Andrew Sullivan | ajs@crankycanuck.ca However important originality may be in some fields, restraint and adherence to procedure emerge as the more significant virtues in a great many others. --Alain de Botton
"Andrew Sullivan" <ajs@crankycanuck.ca> writes: > On Fri, Aug 31, 2007 at 12:30:02PM -0500, Decibel! wrote: >> >> Is it easy to spoof where an incoming connection request is coming from? >> Is there something else that makes ident on 127.0.0.1/32 insecure? > > It shouldn't be easy. Ident uses TCP, which is rather harder to > spoof. Say what? It's actually quite easy to spoof TCP. There are even command-line tools to do it available in most Unix distributions. > If someone can originate spoofed TCP packets from 127.0.0.1, you gots bigger > problems than them being able to lie about the identity of a user. Well yes, there are other insecure services which look at the originating ip address. But hopefully fewer and fewer as time goes on. Once upon a time X was a big target since most X servers shipped trusting 127.0.0.1 and you could slip a request into the first data packet to trust other ip addresses which made attacking it considerably easier. These days X doesn't use ip addresses to handle authorization any more. Also modern distributions, at least on Linux, tend to install ip filters to block packets with source addresses like 127/8 coming from an external interface. However even today I wouldn't be confident that all operating systems do so or that they work correctly in all circumstances. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Fri, Aug 31, 2007 at 07:07:40PM +0100, Gregory Stark wrote: > > > > It shouldn't be easy. Ident uses TCP, which is rather harder to > > spoof. > > Say what? It's actually quite easy to spoof TCP. There are even command-line > tools to do it available in most Unix distributions. Sorry, I should have been more precise. It's hard to spoof TCP easily and usefully. It's trivial to spoof a TCP packet and send it, but because TCP depends on the handshake, there's a bunch of additional overhead that make the whole thing fragile: intermediate firewalls and such like tend to detect these things and prevent their continued use. (This is all in comparison with UDP, which is completely trivial to spoof. In the absence of BCP38, it's also almost impossible to detect, which is why the DNS is so vulnerable these days.) > > If someone can originate spoofed TCP packets from 127.0.0.1, you > > gots bigger problems than them being able to lie about the > > identity of a user. > > Well yes, there are other insecure services which look at the > originating ip address. I was thinking that, if your operating system is accepting packets from 127.0.0.1 on an external interface, you're already in a world of hurt. And if someone is able to fiddle with the packets on your own box, then they have root anyway; they can do anything they want. If you haven't set up your systems so that this kind of attack is impossible from localhost, well, I don't think that anything at the application's level of security is going to do you any good at all. Indeed, I would argue that, for industrial-class data centre use, if you can't use ident between machines, your network security is in very bad shape. (That isn't to say I think it's a good idea; but rather, that I hope the network is well enough run that, even if you did run it, it would not represent a real risk.) -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie
On Fri, Aug 31, 2007 at 02:38:25PM -0400, Andrew Sullivan wrote: > Indeed, I would argue that, for industrial-class data centre use, if > you can't use ident between machines, your network security is in > very bad shape. (That isn't to say I think it's a good idea; but > rather, that I hope the network is well enough run that, even if you > did run it, it would not represent a real risk.) ISTM that if someone breaches your network to the point where they can spoof identd, you're pretty much hosed anyway; so what's the point of hard-coding passwords in a config file somewhere then? -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
"Andrew Sullivan" <ajs@crankycanuck.ca> writes: > On Fri, Aug 31, 2007 at 07:07:40PM +0100, Gregory Stark wrote: >> > >> > It shouldn't be easy. Ident uses TCP, which is rather harder to >> > spoof. >> >> Say what? It's actually quite easy to spoof TCP. There are even command-line >> tools to do it available in most Unix distributions. > > Sorry, I should have been more precise. It's hard to spoof TCP > easily and usefully. It's trivial to spoof a TCP packet and send it, > but because TCP depends on the handshake, Except note that ident is, like X, precisely the kind of protocol where the handshake matters least. Since you all the relevant data comes early in the message you can fire the SYN and the ACK (with the predicted sequence number) with the first data packet off right away. > there's a bunch of additional overhead that make the whole thing fragile: > intermediate firewalls and such like tend to detect these things and prevent > their continued use. They may tend to but would you trust a system that depended entirely on a firewall for security? Firewalls are not omniscient there are always cases they don't cover. Better to use end-to-end secure protocols to begin with. > (This is all in comparison with UDP, which is completely trivial to spoof. > In the absence of BCP38, it's also almost impossible to detect, which is why > the DNS is so vulnerable these days.) Uhm, no DNS is vulnerable because it isn't authenticated. If you think any other unauthenticated protocol is any "more secure" -- whatever that means -- on a public network then you're just depending on obscurity. I assure you that no matter how narrow or difficult the exploit is there's someone out there with the patience to run their attack script long enough to get through. > I was thinking that, if your operating system is accepting packets > from 127.0.0.1 on an external interface, you're already in a world of > hurt. Well then lots of people are in a world of hurt. OSes only started adding filters like this about 8-9 years ago and there are plenty of people running Linux distributions older than this and other operating systems that are slower to take up new ideas. In any case there are common misconfigurations that defeat these kinds of filters too. But yes, if I knew my OS had these filters in place I would be more or less happy to run ident on 127.0.0.1. But I would be a lot happier running on Unix domain sockets where it doesn't depend on an external daemon and ip filters -- just regular kernel credentials. Just as an example, say you're running vmware or something like it and you're bridging it on to your network. Will your ip filters will still kick in for bridged packets? Are you 100.0% sure? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Fri, Aug 31, 2007 at 02:12:03PM -0500, Decibel! wrote: > ISTM that if someone breaches your network to the point where they can > spoof identd, you're pretty much hosed anyway; so what's the point of > hard-coding passwords in a config file somewhere then? True. I personally prefer cryptographic authentication for this reason (but it's not perfect either -- if someone has root, they have root. You're hosed). None of my employers ever seem willing to pay the additional overhead, however. A -- Andrew Sullivan | ajs@crankycanuck.ca The plural of anecdote is not data. --Roger Brinner
On Fri, Aug 31, 2007 at 08:20:20PM +0100, Gregory Stark wrote: > Except note that ident is, like X, precisely the kind of protocol where the > handshake matters least. Since you all the relevant data comes early in the > message you can fire the SYN and the ACK (with the predicted sequence number) > with the first data packet off right away. Well, I certainly wasn't arguing the virtues of ident, in case that's the impression you've formed. > They may tend to but would you trust a system that depended entirely on a > firewall for security? Of course not. But the point is that, in real data centre use, you have pretty serious problems if you have been compromised to the point of people successfully spoofing TCP packets: _someone_ is on your network. I suppose there are people hanging database servers directly off the internet, without a stateful firewall in between, but I don't think those people can really be helped anyway. > Uhm, no DNS is vulnerable because it isn't authenticated. Well, sorta. But the spoofing-based DDoS attacks that are currently so trivial against DNS wouldn't be possible if it used TCP all the time, or if everyone implemented BCP38. > Well then lots of people are in a world of hurt. OSes only started adding > filters like this about 8-9 years ago and there are plenty of people running > Linux distributions older than this and other operating systems that are > slower to take up new ideas. In any case there are common misconfigurations > that defeat these kinds of filters too. Sure. As I said above, I don't think anyone was suggesting that this should be a general strategy. It's just one way to do things, if you know what you're doing. > happy to run ident on 127.0.0.1. But I would be a lot happier > running on Unix domain sockets where it doesn't depend on an > external daemon and ip filters -- just regular kernel credentials. Right, but you can't use UNIX domain sockets with, say, JDBC. > Just as an example, say you're running vmware or something like it > and you're bridging it on to your network. Will your ip filters > will still kick in for bridged packets? Are you 100.0% sure? I dunno, but I do know that I'd test it before I started doing it :) A -- Andrew Sullivan | ajs@crankycanuck.ca In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland