begin quoting John H. Robinson, IV as of Wed, Apr 20, 2005 at 12:18:15PM -0700: > Stewart Stremler wrote: [snip] > > No, it isn't. It's a secret. [snip] > > Erm, that's not the example that comes to mind for me. I'm thinking of > > code obfuscation, unpublished encryption algorithms, and created web-pages > > that have no public links to them. > > What is the difference between a password that no one knows (a secret) > and an url that has no links to it (obscure).
Well, no _public_ links. > Either way, only those that know have it. It cannot be found by any > other means short of brute forcing. Not all password schemes can support > limitless passphrases, but I have seen nastily long urls that would put > most passphrases to shame. I am yet to find a wedserver that will not > support 1024+ long urls. Often, you can deduce those web-pages from inspections of others. A webcomic that has the form "http://foo.bar.baz/comic/YYYYMMDD.html"; and the "http://foo.bar.baz/index.html"; just redirects to that Y/M/D page. So you guess try looking at tomorrow's page.... whoops! Then you see that the artist will let you look at low-res images for ree, and download high-res images if you pay for 'em. You pay for one or two, and notice that the high-res image is the basename of the low-res image rot13'd -- obfuscated, but deducable. > So, where is the practical difference between an unknown token > (password) and an unknown token (url)? Progressions. And, presumably, sniffing the wire to look for those long urls being sent in the clear. When we start encrypting very-long randomized urls, we're dealing with secrets. [snip] > > Keeping just one copy of your data strikes me as a security concern. > > Keeping multiple copies seems an even greater security concern. Conflicting security concerns. Are you worried about loss, or unauthorized distribution? With just one copy, you have to worry about corruption. (So you keep a history of crcs and md5 hashes?) Sometimes, there aren't any simple solutions. :) [snip] > > WE don't run as root because WE run servers and multi-user machines. > > I thought we had established (though not to your satisfaction) that the > single-user computer is a nonesuch. "I cannot refute your assertion, so I declare it meaningless!" If it works for you, great. That just smells too much like a cop-out to me. [snip] > I will agree that there is the single-user mindset. There is also the > ``I am the only one in the world that matters'' mindset. Both are false, > for rather obvious reasons. Heh. We like good network neighbors. We are in the minority. [snip] > > You've already lost your data in this case. Why are you worrying about > > the OS? > > We are working from flawed premises: > > 1) (User) Data is King I don't think this is flawed. > If this is true, then data would be protected. Single user people rarely > (this is well documented) back up (read: protect) their data. Data is > not king. Premise one defeated. Nope. You're presuming that people do what's best for themselves. This is often not the case. It really drives game-theorists batty. > 2) On a single user system, a user compromise is effectively the same as > a root(admin) compromise. > > If this is true, a single user system must exist. We have seen that > these are actually rare. No, we have not. Single-user LINUX systems may be rare, yes. But we have NOT seen that single-user _systems_ are rare. > 3) A user can damage their own data as well as root can. > > This goes back to premise 1, which is flawed. It goes back to premise 1, yes, but I don't accept that premise 1 is flawed. > We can stop discussing > here. However, I contend that root has a larger class of powers that > enable him to destroy a user's data than a user does. Ths allows for > more problems. Kicking a dead body is insulting, but it doesn't matter to the body. It's still dead. > Example: toasting the application. Since a mere user cannot do that, but > root can, this requires the application to be re-installed. Sometimes, > this destroys user data too. Sometimes that data is in the form of > configuration files. > > I am not making an artificial distinction between things like .doc files > or .jpegs, and the rc/.ini files. What are some highly-configured applications? I think this is one of the stronger examples, if we work on it a bit. (For example, ppp configurations. A PITA to set up.) (So that's one-and-an-eighth good reasons...) > Best practice dictates that admin functions be performed by an admin > role, and non-admin stuff be performed by non-admin. Best practices dictate that we have multiple partitions; that we actually enforce least privilege; that we have a system for guaranteeing an actual system login prompt; that we do not let uninspected scripts run with administrative privileges... If we're going to trot out best practices, we ought to trot out the whole kit and caboodle. Which is fine, but that makes _most_ systems guilty of failing to live up to best practices. I'm happy with that! > Because we like car anologies :) (We all do, don't deny it). We wear > normal clothes when driving the car, but wear our grease stained clothes > when working on it. We are the same person, but different roles. Um, I know lots of people that wear the same clothes whether they were working on their car or driving it. (More in my youth; these days, most folks don't seem to work on their own cars too much, myself included.) [snip] > Some people do not learn from other people's mistakes. I won't argue > with them. You are filling the role of that person. To them, I will give Oh, chill already. > them all the rope they want, let them fashion their neat and interesting > nooses, and hang themselves in the noonday sun. When they come back, and > are willing to learn, then we go over everything we have discussed. Did you not catch the bit at the beginning of the thread where I talked about bad habits? > Then they are ready for the teachings of the ancients (to mix metaphors > badly). Before then, you are merely teaching a cow to sing. No, not me. I'm just objecting to sloppy reasoning and wishful thinking. > > No... I'm saying that difficulty for its own sake does not make things > > any better. I demand that additional difficulty in the name of security > > ought to actually provide a concomitant improvement in security. > > We throw this word around - security. What are we actually saying? What > do we actually mean? That important data is not destroyed, corrupted, compromised; that resources are not damaged, made unavailable, or accessed by unauthorized users. (From memory.) > I contend that the whole argument is flawed, because it presumes > conditions that do not and cannot exist. Then you've just self-selected yourself out of the discussion. Atheists don't get to discuss the fine points of theology when they counter every argument that goes against them with 'well, there is no god anyway'. -Stewart "It's important in these sorts of debates to play fair" Stremler
pgpxBJY9FPX2d.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
