Question Database Security (the Initial Connection)

[Chris Hughes]

Hi all

I've read up about database security and tokens etc, but would like to ask a far more fundamental question - I guess I'm missing something somewhere but it just isn't clear to me. At this stage I'm not looking to integrate Windows authentication or other OS level options.

So I want a DB with the blank id disallowed (I think).
I would look to create _user records and each user would essentially have access to all tables (other security handled by the app itself). Or as I understand it deny all, but allow all my users at table level.

So when designing the initial login screen / process, I can't connect to the database (as I have no user) so....

Option 1, without a db connection prompt for credentials and then use a pf file but add the user input credentials to that.
Option 2, create a real low level _user called "connector" that has read access to _user only on each database add this to all pf files, Prompt for credentials and then look to switch all the active connections to that user.

I figure many people must have got over this fundamental hurdle in their quest for compliance etc, any advice or guidance is very much appreciated.

Thanks

Chris

 

[Rob Fitzpatrick]

First off, OpenEdge security isn't exactly intuitive so I get your confusion. Note that the database tools have two separate settings related to blank user: one to disallow blank user access to application tables and one to disallow blank user connections. If you enabled the latter, you would have to authenticate on connection (with -U -P). The problem with this is that now you have to protect the script or other process that contains those credentials. And don't both with Progress' "encrypted passwords" with the genpassword command; they are trivially breakable.

Don't go down this road if you can avoid it. Stop using _User for credential storage. That locks you in to using the ENCODE function for password hashing, which no security auditor will accept. Ideally you want to move the credentials and the point of authentication out of the database. Read the docs on Client Principal; look in the identity management manual.

And if you can get to 11.6.2 or later, look into the Authentication Gateway, a new feature. It moves the point of authentication from the client side to the server side (where it belongs).

 

[RealHeavyDude]

I can only second Rob. The authentication against _User is at best a weak authentication. Regardless whether you supply the credentials with the database connection or if you already connected against the database and then invoke setuserid. The first one, as Rob explained, requires you to provide the credentials in almost clear text while the second one leaves you in a situation that somebody is already connected to your database and it depends on the database's internal security whether that somebody is allowed to do more - or password strength to make brute-force attacks harder to break into it.

IMHO, the client principal object is the way to go. That way you can perform authentication ( be it strong - 2 factor - or weak ) against a dedicated single sign on authentication service which results in an authenticated user identity in form of a client principal object that can then be used to authenticate against an OpenEdge database. That way allows you to fullfill all sorts of requirements that makes auditors happy: You can utilize strong authentication ( for example SSL client certificates against a dedicated infrastructure - like we do - which might even provide location aware access control ). And, from my opinion, since you don't have _User records in your database, nobody can use this vulnerable functionality as an attack vector into your database.

Heavy Regards, RealHeavyDude.