[Owasp-alabama] using SESSION Vars to store sensitive data...

owasp-alabama at lists.owasp.org owasp-alabama at lists.owasp.org
Tue Jun 21 16:09:49 EDT 2011


I agree Chris, sounds like a good plan you have put together. 

 

You mentioned that you may not have control of all the webserver. If that's
the case, when its up and running check to make sure that nothing sensitive
is stored in the web server logs.  This may not be a problem to a limited
"service" account, but could introduce risk if other AD users auth data was
stored.

 

Josh

 

From: owasp-alabama-bounces at lists.owasp.org
[mailto:owasp-alabama-bounces at lists.owasp.org] On Behalf Of
owasp-alabama at lists.owasp.org
Sent: Tuesday, June 21, 2011 3:02 PM
To: owasp-alabama at lists.owasp.org
Subject: Re: [Owasp-alabama] using SESSION Vars to store sensitive data...

 

That sounds like a dang good solution to me.

Regarding the security of the account, could you use key based encryption
where the application kept the key stored in a local configuration file?

That way if the DB ever got compromised, they would have an unusable blob. 


-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org
--
"Si vis pacem, para bellum"
--



On Tue, Jun 21, 2011 at 2:59 PM, <owasp-alabama at lists.owasp.org> wrote:

 

 

 

On Jun 21, 2011, at 2:24 PM, owasp-alabama at lists.owasp.org wrote:





Awesome. I think I see the big picture.

I have this EXACT issue with one of my internal PHP applications. Oddly
enough, this application has the same requirement as yours. It's
authentication system is based on AD, but is platform independent.

We use a service account that has full read access to the AD tree. Any non
authentication requests, such as object attribute queries, use that account.

So if I log in as administrator, and want to create a new user in the
application, the app does a tree query to see if the user account exists in
AD using the service account, not the account of the administrator. Access
to these calls are restricted to users who carry the proper group
membership. 

Another great thing about this, is that we can tightly control the access of
the service account, IE no write permissions to the AD tree. Also, there are
some cases when non admin users of the application might have a legit need
to access an AD object attribute, and this system allows them to do it.
(think delegation of group permissions inside the app)

 

 

Ok yes using a service account is certainly supported in ADLDAP Class im
using, one thing that kept me away from that are the storage security
details of the service account credentials.  This app has **ALL** settings
in the DB, running multi headed, cluster is no problem since any changes are
centralized and updating the code is a simple file copy..

 

anyway, we are back to cleartext storage of the credentials in the DB now...
I understand that since its a limited service account its not "that much" of
a risk, but if i store that, then im bound to get a dozen "how do you
protect it?" questions..  You would ask wouldn't you? ;-)

 

any two way "hash" is essentially obfuscation... which is a waste of time...

 

thoughts there?

 

 





Does that help?



 

it does!  

 

so here is my plan....

 

Login user or admin... access LDAP via individual user credentials to get
authenticated and to get the group memberships.

 

1) Admins are verified as admins via my internal system (the mapping
discussed earlier), then 

2) once they are "determined" to be "admin" then the service account is used
to enumerate the objects i need

3) i will NEVER need to alter anything in the LDAP for my purpose...

4) anytime i access the LDAP for a "list", ill save those responses to
SESSION so i don't have to ask for the same thing twice

 





-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org <http://www.owasp.org/> 
--
"Si vis pacem, para bellum"
--

 

 

 

 





 

On Tue, Jun 21, 2011 at 1:30 PM, <owasp-alabama at lists.owasp.org> wrote:

Below

Chris Story

 

 


On Jun 21, 2011, at 12:54, owasp-alabama at lists.owasp.org wrote:

Would it be possible to store the NTLM challenge result as opposed to the
actual credentials?

 

Assuming that I'm hosted on windows maybe, but one main issue is this needs
to work from any os that is serving the php pages and any web server
software.. Basically the only dependency is php..





Storing the data in the session variables on the server side is not unheard
of, but is certainly sub optimal, as you have eluded to.

If possible, can you revisit how the server retrieves the LDAP attributes?
I'm simply suggesting that rather than find to a solution to a problem that
shouldn't exist, lets remove the problem. So to speak.

 

Since I can't depend on the underlying os for authentication support, I need
to do this at the php level, so allowing php to access the ldap server
provides the "run anywhere" support I need.  The class I'm using
authenticates then queries the directory, since the requests are coming from
the user logged into my app and not the webserver service user (apache, www,
iusr, whatever), it needs to re-authenticate on each query to maintain the
context of that user and not risk cross authentication.






What I'm getting at is that storing LDAP attributes is much less risky than
storing credentials. Typically, I would think that it would be reasonable to
store what attributes you'll need on the first request, but you mentioned
that would be slow. Why?

 

On initial login I only grab email and group memberships from ldap.  In 95%
of the use cases this is all I need, this works fine.  The issue is when an
admin needs to configure or change something, we grab different items from
ldap depending on the task. We would not want to grab the entire ldap just
in case we might need something.  Some of our clients have ***massive***
ldap directories.

 

Example

Add in new group membership --> need all groups from ldap.  Even if I do a
partial query I still need to auth.

 

Sites and services, locations, systems, domains... It gets ugly very fast..

 

They also will need to access multiple domains in one session so each domain
needs to be authed..

 

What I think is ideal is to popup a login box to re-auth the first time you
attempt to access a given domain, then "cache" those creds for later use.

 

Chris

 

All From my phone... Whew!

 

 


-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org <http://www.owasp.org/> 
--
"Si vis pacem, para bellum"
--



On Tue, Jun 21, 2011 at 11:58 AM, <owasp-alabama at lists.owasp.org> wrote:

Ok all, here it goes...

i have a large enterprise product im working on, it has been in production
for some time...  they now want me to add LDAP (AD via LDAP) authentication
support...

- The app is PHP . . . ok ok lets keep the rhetoric down ;-)
- It must run on any web server that supports PHP, and yes all functions
should work from any hosted OS
- Backend is Mysql, (but thats not really relevant...)

Im using ADLDAP.php, seems to be fairly solid... --->
http://adldap.sourceforge.net/

i can authenticate fine from any hosted OS, all is great there...

here's the problem..

i often have to go back to the ldap server during the course of setup to get
different values, to do this i need to re-authenticate with the LDAP server
on every request... so this means the user could have to enter the
credentials multiple times... that sucks...

the only solution is to store the user / pass the first time they enter it
somewhere, so i can grab it and resend to LDAP when i need it...

so where to store it?

- i dont want to store them anywhere permanent of course
- i only need it for the existing session
- it really only important when the admin is changing stuff for users or
ldap config.
- i cant use a one way hash, cause i need to send it to another server...
- i could do some sort of obfuscation, but is that really secure? better
than nothing?

Options
- Session Var certainly an option... but other than the obvious session file
on the server are there other risks?

- i could store it in the DB, but then thats seems more risky than the
session because there are more points of access..

- an obvious one is to pull all the data from LDAP on the first login and
stuff that in a session, but on large LDAP it will slow user login time
down... non-starter...

of course regular session security needs to be optimal...


IDEAS or COMMENTS?  I can handle flames as long as they are intelligent...
:-)

Chris
_______________________________________________
Owasp-alabama mailing list
Owasp-alabama at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-alabama

 

_______________________________________________
Owasp-alabama mailing list
Owasp-alabama at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-alabama


_______________________________________________
Owasp-alabama mailing list
Owasp-alabama at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-alabama


_______________________________________________
Owasp-alabama mailing list
Owasp-alabama at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-alabama

 


_______________________________________________
Owasp-alabama mailing list
Owasp-alabama at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-alabama

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1382 / Virus Database: 1513/3717 - Release Date: 06/21/11

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20110621/ecc0b16b/attachment-0001.html 


More information about the Owasp-alabama mailing list