Guys, Nevermind on the below, after examining the page source, I found it in the story_summary block... thanks for your help. S. "On another topic, something a bit more technical, I've noticed that the posts that appear on the front page, that are populated by the |CONTENT| special key, under Firefox are separated top to bottom by a dashed line that spans the column. I like this appearance, however under IE6 this line does not appear. I would like to possibly add a <hr> tag to create a more distinct separator that would appear in both browser types (I don't have access to Safari so I'm not sure how the page renders under that browser). My perl is limited, and something I'd like to work on of course, but where in the application is the |CONTENT| key functions located? I understand that in order to change this appearance, the necessary tags (or more accurately the perl code needed to place these tags correctly) would have to be added in one of the perl modules. Would this be a relatively easy change?" On Tue, Feb 26, 2008 at 9:05 AM, Steve Baetz <sbaetz at gmail.com> wrote: > Colin, > > Agreed, technically providing a security solution must also be closely > coupled with a security policy at the Layer 8 level. That is the super-user > should never be used to post/comment/approve, etc. anything that's customer > facing. The problem with security is that the solution to the problem is > one part technical, two parts organic. Technical is self-explanatory, the > organic pieces are the policy implemented by the admin, and this followed by > the organic will to enforce compliance with that policy. My suggestion is > that there are always methods to add layers here and there to make the task > of finding the admin account more difficult. > > For the site I am currently constructing, I have designated an admin > account that is purely for that purpose and not for any posting etc. And > obviously I've determined the necessary organic components to implementing > this protection to the site. ;-) However, it causes me concern to see it > pop up in a user search. > > On another topic, something a bit more technical, I've noticed that the > posts that appear on the front page, that are populated by the |CONTENT| > special key, under Firefox are separated top to bottom by a dashed line that > spans the column. I like this appearance, however under IE6 this line does > not appear. I would like to possibly add a <hr> tag to create a more > distinct separator that would appear in both browser types (I don't have > access to Safari so I'm not sure how the page renders under that browser). > My perl is limited, and something I'd like to work on of course, but where > in the application is the |CONTENT| key functions located? I understand > that in order to change this appearance, the necessary tags (or more > accurately the perl code needed to place these tags correctly) would have to > be added in one of the perl modules. Would this be a relatively easy > change? > > Thanks Guys. > Steve > > > On Sat, Feb 23, 2008 at 3:26 PM, Colin Hill <hillct at scoophost.com> wrote: > > > Steve, > > Simply excluding a specific user from search results wouldn't be > > sufficient. It would also require that the administrative user never be > > used to post stories to the site, since an attacker could simply through > > process of elimination, identify superusers by locating accounts that do > > not appear in search results. As Janra mentioned, Scoop uses role-based > > access control, so any role/group could be defined with any set of > > permissions, thus hiding specific users from search results doesn't buy > > you much, unless you create a privilege granted to certain roles/groups > > to exclude_from_user_search such that any user group could be excluded > > from search results. > > The major problem with this approach is it represents exactly the > > type of security through obscurity that you're arguing against. > > Obfuscation through exclusion from search results is the same as > > obfuscation through changing username. Regardless, an attacker could > > simply go through every user by UID. Preventing identification of a > > privileged account is not a security measure, regardless of your > > methodology. > > Instead, all users should be encouraged to set secure passwords that > > could not be guessed via a brute-force attack. With this in mind, it > > would be reasonable to implement in Scoop, password quality checking > > similar to that used by any modern implementation of the UNIX passwd > > command. > > > > Just my two cents... > > > > Best Regards, > > Colin Hill > > > > -- > > Scoophost.com - a service of Pinnacle Digital > > Scoop consulting and hosting services > > > > > > > Date: Fri, 22 Feb 2008 20:36:51 -0500 > > > From: "Steve Baetz" <sbaetz at gmail.com> > > > Subject: Re: [Scoop-help] User Search - Security Issue? > > > To: janra at write-on.org > > > Cc: scoop-help at lists.kuro5hin.org > > > Message-ID: > > > <93f31b2a0802221736t3ef14ea2n126d47c3313a207f at mail.gmail.com> > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hi Janra, > > > > > >>From a security standpoint, obfuscation or hiding in plain sight is > > not > > > necessarily a security measure (My day job is a Security SE for a very > > large > > > network equipment company). And you're quite correct about many > > software > > > packages advertising who is admin and who isn't (everyone else ;) ... > > I > > > would agree that changing the name is a prudent measure, but in > > addition, if > > > the search results left out any account with the UID of 1 that would > > hide it > > > altogether, thus adding another layer on the onion so to speak. :) > > > > > > Just my thoughts. > > > > > > Regards, > > > Steve > > _______________________________________________ > > Scoop-help mailing list > > Scoop-help at lists.kuro5hin.org > > http://lists.kuro5hin.org/mailman/listinfo/scoop-help > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kuro5hin.org/pipermail/scoop-help/attachments/20080227/f208895b/attachment.html