RE: [SC-L] Credentials for Application use
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 the entity authenticating the password. A fixed password used to unlock a token by entering it into keys on the token is not bad. Use the keyboard associated with a programmable computer, and you increase the risks monumentally. -- Larry Kilgallen
RE: [SC-L] Credentials for Application use
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 respective application realms. As >such, it is a front-end technology; the back-end applications don't know >anything about this. That is _one_ (relatively insecure) method of implementing single sign-on. The general definition of single sign-on is that a user only logs on once to access a variety of computer applications. For some applications, relying entirely on Microsoft's credentials is adequate. For some applications, relying on the TSO login is adequate. For some applications, relying on Kerberos credentials is adequate. etc. -- Larry Kilgallen
RE: [SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1
After getting served a large helping of humble pie and ruminating on the texture and taste thereof, Gizmo responded with: Good points, Dana, and eloquently put. I think you have stated what I was really driving at, much better than I did. :-) However, if you think that MS won't find a way to drive a revenue stream out of this, then I believe you will be surprised. After all, the AV companies do it now. Later, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dana Epp Sent: Wednesday, May 11, 2005 1:19 PM To: Gizmo Cc: SC-L@securecoding.org Subject: Re: [SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1 I don't think its fair to paint such a broad stroke about Microsoft's intent. Microsoft is a business. And a business that has to weigh its investments carefully through its metrics driven organization, just like every other successful business out there. They enter into markets for three general reasons: 1) Paranoia: Put bluntly, if they see a perceived threat to their Windows or Office revenues (where they make their real profits), they step in. 2) Numbers: Big, broad markets with no dominant players that would be low touch to them are attractive 3) Grief: Taking to much grief from customers and the press can hurt their company, and their stockprice. Summing that up, Microsoft goes after markets with billion-dollar ambitions, focusing on horizontal software that can strengthen their Windows/Office offerings while preventing their platform from looking bad. Microsoft isn't focusing on security to be good samaritans, or to find billion dollar revenues. With such a poor track record in the past they had to deal with the GRIEF caused by poor decisions a decade ago. (Longer if you ask me) The impact of those decisions are hurting their platform now, and they came to realize they need to realign their business practices accordingly. In this light security is not a technology problem, but really a business one. We see that in the (in)decision many businesses take (not just Microsoft) on when and where to bolt on security, if at all. 10 years ago very few commercial software companies followed secure coding best practices... mostly because very few best practices even existed that people knew about. And those that did, didn't align with the business mentality of "build and ship". I think you are kidding yourself if you believe Microsoft is in it to build NEW major revenue streams off the offerings. If you consider the investment they are putting into their security related programs, you would find that it would be a POOR decision if that was the case. Their investment into security goes deeper then that. They have a responsibility to their existing customers, and the new ones they hope to gain in ensuring that in this ever changing digital divide that they take a more serious stance on security. Its the right thing to do, and now its good business. Spending the last decade as the punching bag for security (and rightfully so) has given them enough black eyes to realize with such a dominant position in the marketplace, they need to be more responsible... or lose customers. So its about protecting marketshare, not building new ones from it. At the same time, I don't blame them for going further and building security in to upcoming products to make their product offerings better. Remember my Point #1? To protect their dominance in the OS market they will need to make Longhorn MUCH better than Srv03/XP is. Investments in things like LUA are breaking the shackles of the OLD broken way users run applications on Microsoft's platforms and offers a mechanism to run in a safer environment using least privilege. These are tremendous changes in the attitudes and thinking of security on the platform, while offering users a comfortable environment to do their job. In the end, thats all the customer cares about. A safe and secure computing environment to let them get their job done. I think you are incorrect in saying that: "their approach is NOT "Let's make the OS more secure so that this crap can't get installed to start with" They ARE doing that. Take a closer look at the new security infrastructure in Longhorn. Things like LUA are designed SPECIFICALLY for that. They are reducing the attack surface of application behaviour by confining and containing access rights within the account itself. They are making tools like prefast and Static Driver Verifier (SDV) that can do static code analysis to strengthen the code base touching their kernel. The new driver framework is cleaner and the resulting code runs safer. Decisions to tear down the way processes execute in the OS are now rewritten in Longhorn to ensure trust boundaries are maintained (Longhorn has an entirely new mechanism for CreateProcess locked in the kernel for safer and more trusted execution). These all lead to a safer environment for everyone. Top that off with the userland applications t
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 to have to deal with multiple sets of credentials and different login procedures for different apps/systems. Login requirements for various apps and backend systems vary. The SSO system deals with the discrepancies. 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); (2) its own trustworthiness and assurance. An SSO a piece of highly trusted software in any environment - essentially "the keys to the kingdom". Thus it needs to be highly trustworthy and very strongly protected against compromise. To my mind, that means (1) rigorous security testing before acquisition and before deployment (not just relying on Common Criteria EAL, because that doesn't indicate the real security of anything); (2) a higher-assurance platform than Linux, UNIX, Windows, or OS X - at the very least, a "hardened", minimized operating system like those used to host firewalls. Better yet, correctly-configured TSol. -- Karen Goertzel, 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 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. However, once the DB is secured, > you can't > access it unless you have the owner name, and giving out the > owner name to > everyone who uses the app to access the DB pretty much > defeats the whole > purpose of the exercise. > > The only way can see to deal with this is something > similar to what I've > done in my app: > > The user provides the management console with the password to > secure the DB. > The app encrypts the password using the blowfish algorithm > and a private > key. It then postpends a SHA1 hash, Base64 encodes the > result, and stores > it in three places: a local configuration file, a remote > configuration file, > and the registry. All three stores are secured using an ACL > such that only > the user the main server app runs under has access to the > data. In the > event that one of the stores is corrupted or tampered with > (as determined by > the SHA1 hash) voting logic is used to determine which stored > password is to > be discarded. > > I imagine that someone here has a better idea, and if so, I'd > love to hear > it. > > Later, > Chris > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Mikey > Sent: Tuesday, May 10, 2005 6:49 PM > To: SC-L@securecoding.org > Subject: [SC-L] Credentials for Application use > > > This is a broad question around the current practices and > recommendation of > what not to do when it comes to credentials used by > applications to gain > access to a resource or data stored elsewhere. > > As an example, I have some middleware components that need to > gain access > to a data repository that contains sensitive information. The > middleware > components and data repository reside in separate, distinct security > boundaries protected by differing authentication and access control > mechanisms. > > Application developers insists the only way to gain access to the data > repository is to create a set of credentials for the > repository that only > they can use. But because the middleware components are using > it, there is > no requirement for a user to enter those credentials in order to > authenticate usage. I guess I wouldn't want the users to know > the details > of this set of credentials either. > > Short of creating a user credential for each user accessing > the application > on the data repository side, they insist that they need to > store the userid > and password in a static format somewhere on the middleware > server. For > example, a configuration file or some part of the operating system. > > Is there a best practice guideline for this scenario? What have other > people in the same situation been doing here? > > >
Re: [SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1
I don't think its fair to paint such a broad stroke about Microsoft's intent. Microsoft is a business. And a business that has to weigh its investments carefully through its metrics driven organization, just like every other successful business out there. They enter into markets for three general reasons: 1) Paranoia: Put bluntly, if they see a perceived threat to their Windows or Office revenues (where they make their real profits), they step in. 2) Numbers: Big, broad markets with no dominant players that would be low touch to them are attractive 3) Grief: Taking to much grief from customers and the press can hurt their company, and their stockprice. Summing that up, Microsoft goes after markets with billion-dollar ambitions, focusing on horizontal software that can strengthen their Windows/Office offerings while preventing their platform from looking bad. Microsoft isn't focusing on security to be good samaritans, or to find billion dollar revenues. With such a poor track record in the past they had to deal with the GRIEF caused by poor decisions a decade ago. (Longer if you ask me) The impact of those decisions are hurting their platform now, and they came to realize they need to realign their business practices accordingly. In this light security is not a technology problem, but really a business one. We see that in the (in)decision many businesses take (not just Microsoft) on when and where to bolt on security, if at all. 10 years ago very few commercial software companies followed secure coding best practices... mostly because very few best practices even existed that people knew about. And those that did, didn't align with the business mentality of "build and ship". I think you are kidding yourself if you believe Microsoft is in it to build NEW major revenue streams off the offerings. If you consider the investment they are putting into their security related programs, you would find that it would be a POOR decision if that was the case. Their investment into security goes deeper then that. They have a responsibility to their existing customers, and the new ones they hope to gain in ensuring that in this ever changing digital divide that they take a more serious stance on security. Its the right thing to do, and now its good business. Spending the last decade as the punching bag for security (and rightfully so) has given them enough black eyes to realize with such a dominant position in the marketplace, they need to be more responsible... or lose customers. So its about protecting marketshare, not building new ones from it. At the same time, I don't blame them for going further and building security in to upcoming products to make their product offerings better. Remember my Point #1? To protect their dominance in the OS market they will need to make Longhorn MUCH better than Srv03/XP is. Investments in things like LUA are breaking the shackles of the OLD broken way users run applications on Microsoft's platforms and offers a mechanism to run in a safer environment using least privilege. These are tremendous changes in the attitudes and thinking of security on the platform, while offering users a comfortable environment to do their job. In the end, thats all the customer cares about. A safe and secure computing environment to let them get their job done. I think you are incorrect in saying that: "their approach is NOT "Let's make the OS more secure so that this crap can't get installed to start with" They ARE doing that. Take a closer look at the new security infrastructure in Longhorn. Things like LUA are designed SPECIFICALLY for that. They are reducing the attack surface of application behaviour by confining and containing access rights within the account itself. They are making tools like prefast and Static Driver Verifier (SDV) that can do static code analysis to strengthen the code base touching their kernel. The new driver framework is cleaner and the resulting code runs safer. Decisions to tear down the way processes execute in the OS are now rewritten in Longhorn to ensure trust boundaries are maintained (Longhorn has an entirely new mechanism for CreateProcess locked in the kernel for safer and more trusted execution). These all lead to a safer environment for everyone. Top that off with the userland applications they are strengthening with tools like FxCop, codebase permission sets in managed code and things like the /gs switch in their compilers, and Microsoft is slowly causing the adoption of secure coding to the 3rd parties out there as well. With all the education and training thats being offered for free, they are TRYING to make it safer for everyone. SD3+C isn't just a marketing term... its something they are trying to distill in their organization, which in turn should spill out to 3rd parties using their tools and technologies. I agree with your position on the perceived simplicity that the user needs in their operating sys
RE: [SC-L] Credentials for Application use
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 <[EMAIL PROTECTED]>: > 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. However, once the DB is secured, you can't > access it unless you have the owner name, and giving out the owner name to > everyone who uses the app to access the DB pretty much defeats the whole > purpose of the exercise. > > The only way can see to deal with this is something similar to what I've > done in my app: > > The user provides the management console with the password to secure the DB. > The app encrypts the password using the blowfish algorithm and a private > key. It then postpends a SHA1 hash, Base64 encodes the result, and stores > it in three places: a local configuration file, a remote configuration file, > and the registry. All three stores are secured using an ACL such that only > the user the main server app runs under has access to the data. In the > event that one of the stores is corrupted or tampered with (as determined by > the SHA1 hash) voting logic is used to determine which stored password is to > be discarded. > > I imagine that someone here has a better idea, and if so, I'd love to hear > it. > > Later, > Chris > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Mikey > Sent: Tuesday, May 10, 2005 6:49 PM > To: SC-L@securecoding.org > Subject: [SC-L] Credentials for Application use > > > This is a broad question around the current practices and recommendation of > what not to do when it comes to credentials used by applications to gain > access to a resource or data stored elsewhere. > > As an example, I have some middleware components that need to gain access > to a data repository that contains sensitive information. The middleware > components and data repository reside in separate, distinct security > boundaries protected by differing authentication and access control > mechanisms. > > Application developers insists the only way to gain access to the data > repository is to create a set of credentials for the repository that only > they can use. But because the middleware components are using it, there is > no requirement for a user to enter those credentials in order to > authenticate usage. I guess I wouldn't want the users to know the details > of this set of credentials either. > > Short of creating a user credential for each user accessing the application > on the data repository side, they insist that they need to store the userid > and password in a static format somewhere on the middleware server. For > example, a configuration file or some part of the operating system. > > Is there a best practice guideline for this scenario? What have other > people in the same situation been doing here? > > >
RE: [SC-L] Credentials for Application use
Neither impersonation nor delegation work for this environment: the DB itself is encrypted using the owner name as the key. It doesn't matter in the slightest what user rights you have to the server; if you don't have the owner name you can't decrypt the data in the DB (at least, not without a LOT of effort). As I understand it, delegation and impersonation are of value in situations where you have multiple users directly accessing the same resources, or you wish to be able to log who accessed a resource and when. Ideally, in a client-server architecture only the server accesses the resources; therefore only the server needs access and the server can authenticate the client in whatever manner it chooses as well as logging who the access was for. Or am I missing your point? Later, Chris -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 10:21 AM To: Gizmo Cc: SC-L@securecoding.org Subject: RE: [SC-L] Credentials for Application use 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.ht ml & http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation .html -gp Quoting Gizmo <[EMAIL PROTECTED]>: > 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. However, once the DB is secured, you can't > access it unless you have the owner name, and giving out the owner name to > everyone who uses the app to access the DB pretty much defeats the whole > purpose of the exercise. > > The only way can see to deal with this is something similar to what I've > done in my app: > > The user provides the management console with the password to secure the DB. > The app encrypts the password using the blowfish algorithm and a private > key. It then postpends a SHA1 hash, Base64 encodes the result, and stores > it in three places: a local configuration file, a remote configuration file, > and the registry. All three stores are secured using an ACL such that only > the user the main server app runs under has access to the data. In the > event that one of the stores is corrupted or tampered with (as determined by > the SHA1 hash) voting logic is used to determine which stored password is to > be discarded. > > I imagine that someone here has a better idea, and if so, I'd love to hear > it. > > Later, > Chris > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Mikey > Sent: Tuesday, May 10, 2005 6:49 PM > To: SC-L@securecoding.org > Subject: [SC-L] Credentials for Application use > > > This is a broad question around the current practices and recommendation of > what not to do when it comes to credentials used by applications to gain > access to a resource or data stored elsewhere. > > As an example, I have some middleware components that need to gain access > to a data repository that contains sensitive information. The middleware > components and data repository reside in separate, distinct security > boundaries protected by differing authentication and access control > mechanisms. > > Application developers insists the only way to gain access to the data > repository is to create a set of credentials for the repository that only > they can use. But because the middleware components are using it, there is > no requirement for a user to enter those credentials in order to > authenticate usage. I guess I wouldn't want the users to know the details > of this set of credentials either. > > Short of creating a user credential for each user accessing the application > on the data repository side, they insist that they need to store the userid > and password in a static format somewhere on the middleware server. For > example, a configuration file or some part of the operating system. > > Is there a best practice guideline for this scenario? What have other > people in the same situation been doing here? > > >
RE: [SC-L] Credentials for Application use
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 respective application realms. As such, it is a front-end technology; the back-end applications don't know anything about this. Since my application is a server in a client-server architecture, it is a back-end app. In any case, SSO wouldn't help the situation where the data are encrypted by the password, if the data are accessed by more than one user. The idea behind this implementation is to ensure that even if a bad guy gains access to the server and the data files of the DB, he still can't get at the actual data without the key. Or am I missing something? Later, Chris -Original Message- From: Goertzel Karen [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 to have to deal with multiple sets of credentials and different login procedures for different apps/systems. Login requirements for various apps and backend systems vary. The SSO system deals with the discrepancies. 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); (2) its own trustworthiness and assurance. An SSO a piece of highly trusted software in any environment - essentially "the keys to the kingdom". Thus it needs to be highly trustworthy and very strongly protected against compromise. To my mind, that means (1) rigorous security testing before acquisition and before deployment (not just relying on Common Criteria EAL, because that doesn't indicate the real security of anything); (2) a higher-assurance platform than Linux, UNIX, Windows, or OS X - at the very least, a "hardened", minimized operating system like those used to host firewalls. Better yet, correctly-configured TSol. -- Karen Goertzel, 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 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. However, once the DB is secured, > you can't > access it unless you have the owner name, and giving out the > owner name to > everyone who uses the app to access the DB pretty much > defeats the whole > purpose of the exercise. > > The only way can see to deal with this is something > similar to what I've > done in my app: > > The user provides the management console with the password to > secure the DB. > The app encrypts the password using the blowfish algorithm > and a private > key. It then postpends a SHA1 hash, Base64 encodes the > result, and stores > it in three places: a local configuration file, a remote > configuration file, > and the registry. All three stores are secured using an ACL > such that only > the user the main server app runs under has access to the > data. In the > event that one of the stores is corrupted or tampered with > (as determined by > the SHA1 hash) voting logic is used to determine which stored > password is to > be discarded. > > I imagine that someone here has a better idea, and if so, I'd > love to hear > it. > > Later, > Chris > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Mikey > Sent: Tuesday, May 10, 2005 6:49 PM > To: SC-L@securecoding.org > Subject: [SC-L] Credentials for Application use > > > This is a broad question around the current practices and > recommendation of > what not to do when it comes to credentials used by > applications to gain > access to a resource or data stored elsewhere. > > As an example, I have some middleware components that need to > gain access > to a data repository that contains sensitive information. The > middleware > components and data repository reside in separate, distinct security > boundaries protected by differing authentication and access control > mechanisms. > > Application developers insists the only way to gain access to the data > repository is to create a set of credentials for the > repository that only > they can use. But because the middleware components are using > it, there is > no requirement for a user to enter those credentials in order to > authenticate usage. I guess I wouldn't want the users to know > the det
RE: [SC-L] Credentials for Application use
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. However, once the DB is secured, you can't access it unless you have the owner name, and giving out the owner name to everyone who uses the app to access the DB pretty much defeats the whole purpose of the exercise. The only way can see to deal with this is something similar to what I've done in my app: The user provides the management console with the password to secure the DB. The app encrypts the password using the blowfish algorithm and a private key. It then postpends a SHA1 hash, Base64 encodes the result, and stores it in three places: a local configuration file, a remote configuration file, and the registry. All three stores are secured using an ACL such that only the user the main server app runs under has access to the data. In the event that one of the stores is corrupted or tampered with (as determined by the SHA1 hash) voting logic is used to determine which stored password is to be discarded. I imagine that someone here has a better idea, and if so, I'd love to hear it. Later, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mikey Sent: Tuesday, May 10, 2005 6:49 PM To: SC-L@securecoding.org Subject: [SC-L] Credentials for Application use This is a broad question around the current practices and recommendation of what not to do when it comes to credentials used by applications to gain access to a resource or data stored elsewhere. As an example, I have some middleware components that need to gain access to a data repository that contains sensitive information. The middleware components and data repository reside in separate, distinct security boundaries protected by differing authentication and access control mechanisms. Application developers insists the only way to gain access to the data repository is to create a set of credentials for the repository that only they can use. But because the middleware components are using it, there is no requirement for a user to enter those credentials in order to authenticate usage. I guess I wouldn't want the users to know the details of this set of credentials either. Short of creating a user credential for each user accessing the application on the data repository side, they insist that they need to store the userid and password in a static format somewhere on the middleware server. For example, a configuration file or some part of the operating system. Is there a best practice guideline for this scenario? What have other people in the same situation been doing here?
RE: [SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1
Microsoft is all about making Windows 'more secure' because they see a potential revenue stream. Note that their approach is NOT "Let's make the OS more secure so that this crap can't get installed to start with"; rather, it is "Let's graft more crap onto the system and then sell people a subscription so that they can be protected from the problems we have created, at least most of the time". To be sure, I like Apple's approach even less. "We want to help the customer protect their computer"?! I realize that security requires the cooperation of the user, but providing the typical user with a readily available list of the processes running in the system isn't going to do anything but confuse the poor user. We need to remember that users are generally illiterate when it comes to the details of how their computer functions. That's why they are USERS. They don't know (or care) how or why their computer works. All they care about is that it does what they need for it to do. Quite frankly, that is all they really SHOULD have to care about. It is not necessary for me to understand all the gory intimate details of how my car works in order for me to use it in a safe fashion. The same should be true of my computer. I dunno, maybe I'm way off base and just too cynical for my own good, but that's the way I see it. Later, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kenneth R. van Wyk Sent: Tuesday, May 10, 2005 6:37 AM To: Secure Coding Mailing List Subject: [SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1 FYI, somewhat interesting story today on ZDNet (see http://news.zdnet.com/2100-1009_22-5697133.html?tag=st.prev) about operating system makers paying more attention to security. Note the differing (public) statements by Microsoft and Apple... Being fundamentally a "glass half full" sort of person, I think that it's refreshing to hear that OS vendors are making their products' security a higher priority than it's typically been in the past. There's also an implicit message here regarding a proactive software security posture vs. "firewall and IDS it" after the product is released. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
[SC-L] Credentials for Application use
This is a broad question around the current practices and recommendation of what not to do when it comes to credentials used by applications to gain access to a resource or data stored elsewhere. As an example, I have some middleware components that need to gain access to a data repository that contains sensitive information. The middleware components and data repository reside in separate, distinct security boundaries protected by differing authentication and access control mechanisms. Application developers insists the only way to gain access to the data repository is to create a set of credentials for the repository that only they can use. But because the middleware components are using it, there is no requirement for a user to enter those credentials in order to authenticate usage. I guess I wouldn't want the users to know the details of this set of credentials either. Short of creating a user credential for each user accessing the application on the data repository side, they insist that they need to store the userid and password in a static format somewhere on the middleware server. For example, a configuration file or some part of the operating system. Is there a best practice guideline for this scenario? What have other people in the same situation been doing here?
[SC-L] Secure programming with the OpenSSL API, Part 2: Secure handshake
FYI, there's a new(ish) article by Kenneth Ballard out on IBM's developerWorks site, on the topic of secure use of OpenSSL. It's actually part 2 in a series, but there's a pointer there to part 1 also. The abstract follows, along with the URL to the full article: Securing the handshake during a Secure Sockets Layer session (SSL) is vital, since almost all of the security involving the connection is set up inside the handshake. Learn how to secure the SSL handshake against a man in the middle (MITM) attack -- in which the intruding party masquerades as another, trusted source. This article also introduces the concept of digital certificates and how the OpenSSL API handles them. http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?ca=dgr-lnxw02SecureHandshake Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
