Gizmo [EMAIL PROTECTED] wrote:
the efficacy of the encryption is of some question.
Basically, it keeps honest people honest.
Sounds a little better than I thought, but I'd still be worried about the
owner name leaking into less honest hands.
1) The app is architected around the Btrieve
Gizmo [EMAIL PROTECTED] wrote:
I have a similar situation in one of my applications. The
customer wishes to secure the database. Since we use a Btrieve
database, the only way to do
this is be setting an owner name on the DB, and then
encrypting using the owner name as the password.
Chris,
Your situation is a little unique in that you encrypt the data with the
password. The data backend I was referring to is simply a backend database
like an SQL Server, Oracle 8i or DB2 data repository. All users need to do
to get access to it is to authenticate to it and then have the
If you are just talking about a password to access a db, the 'typical'
approach (at least the approach I use) is just to store that password
in the code/config file. You may like to add a layer to that by
encrypting it in some config file, and requiring a 'decryption'
(initialisation) of the
-l@securecoding.org
Subject: Re: [SC-L] Credentials for Application use
Gizmo [EMAIL PROTECTED] wrote:
I have a similar situation in one of my applications. The
customer wishes to secure the database. Since we use a Btrieve
database, the only way to do
this is be setting an owner name
I'm wondering whether role-based credentials, vs. individual user
credentials, might not make more sense here. Could the database owner
key be issued to a role vs. an individual identity? In this way, your
human users could be associated with a role that has a right to issue a
query to the
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 10:29 AM
To: Gizmo; SC-L@securecoding.org
Subject: RE: [SC-L] Credentials for Application use
Isn't a Single Sign-on System supposed to address exactly this kind of
problem?
Users need to be authenticated individually. Also, they don't want
Keith Brown has a good discussion of at least one of the design choices, namely
delegation vs. impersonation:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation.html
-gp
Quoting Gizmo
, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gizmo
Sent: Wednesday, May 11, 2005 10:52 AM
To: SC-L@securecoding.org
Subject: RE: [SC-L] Credentials for Application use
I have a similar
At 11:00 AM -0500 5/11/05, Gizmo wrote:
Maybe I don't fully understand the concept of Single Sign-On.
As I understand it, SSO allows a user to login to an application portal, and
all of the applications that user accesses via that portal know who the user
is and what rights they have within their
At 11:28 AM -0400 5/11/05, Goertzel Karen wrote:
Of course, and SSO is only as secure as (1) the assurance of the
credential on which it bases its authentication decisions (a static
password with an SSO is a really STUPID idea);
That depends on the security of the channel between the user and
11 matches
Mail list logo
