[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:02:23 EDT 2011


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
> --
> "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>
>> 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/>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>Owasp-alabama at lists.owasp.org
>>>  <https://lists.owasp.org/mailman/listinfo/owasp-alabama>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20110621/3a440f92/attachment.html 


More information about the Owasp-alabama mailing list