Facebook Photo Hack Bypasses Privacy Settings
Do you use Facebook? Since over 700 million people do, the odds are pretty high that you fall in this category. Are you concerned with your privacy and want control over who sees your content? Have you taken all the steps necessary to keep your private information private and feel pretty good about yourself? Well think again. While you may be taking every precaution to keep your data private, some items (such as your photos) are totally open. Still feel good about yourself? Keep reading.
Let’s say that you are on vacation and decide to take a few pictures to memorialize the trip.
You want to share your pictures, but you only want to do so with some of your closest friends (you don’t want these photos to be public). So, you select the upload photo option, point to the picture on your local computer, make sure that the Friends option is selected, and click Post.
The picture appears on your wall where only you and your friends can see it. You verify this by viewing the audience for the picture as follows:
Your friends comment and you all get a big laugh from the picture. But one of your not so close friends thinks it would be funny to show the picture to someone else – outside of your friends community – without your permission. Now, they could download the picture to their local computer and upload it somewhere else, but that takes too many steps – Facebook makes it much easier for you to be compromised.
Simply click on the image to open Facebook’s photo viewer.
Now right-click on the photo and select “Copy Image URL” from the browser menu that opens. You will have copied something like this:
If you look at the URL, you can see that this image is not hosted on Facebook’s site. Instead, it is hosted on Akamai’s site (a place where your privacy settings do not apply). By simply knowing this photo’s URL, anyone in the world can see this picture. All your “friend” has to do is share out this URL and all the time and efforts that you have taken to be private are now out the window.
Don’t believe me? Try this for yourself. Or simply click on the link above to see a picture that I have supposedly made private in Facebook.
Disjointed Identity
Having my identity located in so many different databases is like wearing multiple watches
You never really know what time it is!
Book Review: Mockingjay
![]() |
Mockingjay by Suzanne Collins Bill has read this book
|
||
| Comment:The war between the districts and the Capitol are brought to a conclusion in the final book in the series.
This book was a must read for anyone who has read the previous two – if anything to see how the story ends. But I must honestly say, I was not pleased with the writing of the third book. It was not an issue with the plot (that was good), nor was it an issue with the fate of many of the characters (I was OK with that). What made this book disappointing to me was the way the final story was told and how its narrative deviated from the previous two books. While I enjoyed the story-telling in the first two books, the third and final one took on a more serious tone. It was a deep, dark look into Katniss’ soul as she was faced with situations more directed towards an adult audience – not the younger audience for which this series was written. The characters are angrier, the story takes on too many twists and turns that are hard to follow (I had to reread several sections just to understand what Collins was trying to say), and the finale scene in district 12 seems rushed and not fully developed (its almost as if the book had to be limited to a certain page count before it could be printed). Don’t get me wrong, I thoroughly enjoyed the entire series and like many others, I am eagerly anticipating the movies. I just think this third and final book could have been written better, ended the story with a bang, and could have put Collins on par with Tolkien, Feist, or Lewis. Unfortunately, I believe that she missed her opportunity. |
|||
Book Review: Catching Fire
![]() |
Catching Fire
Bill has read this book
|
||
| Comment:The second book in the Hunger Games trilogy. If you enjoyed the first book, you will definitely like this one as well.
Katniss and Peeta are sent back into the arena along with other surviving victors to determine the champion of champions. The plot is somewhat predictable and the finale is not altogether unsurprising – but the story is very nicely told (and worth the read). There are some definite twists and turns and some very memorable moments (i.e. Katniss on stage as she is set on fire). It also introduces some lovable new characters (i.e. Fennick) and adds to the list of those whom you love to hate. Suffice to say the key players live – but not so happily ever after (after all, this is a trilogy). |
|||
Single Sign-On Explained
So what is SSO and why do I care?
SSO is an acronym for “Single Sign-On”. There are various forms of single sign-on with the most common being Enterprise Single Sign-On (ESSO) and Web Single Sign-On (WSSO).
Each method utilizes different technologies to reduce the number of times a user has to enter their username/password in order to gain access to protected resources.
Note: There are various offshoots from WSSO implementations – most notably utilizing proxies or portal servers to act as a central point of authentication and authorization.
Enterprise Single Sign-On
In ESSO deployments, software typically resides on the user’s desktop; the desktop is most commonly Microsoft. The software detects when a user launches an application that contains the username and password fields. The software “grabs” a previously saved username/password from either a local file or remote storage (i.e. a special entry in Active Directory), enters these values into the username and password fields on behalf of the application, and submits the form on behalf of the user. This process is followed for every new application that is launched that contains a username and password field. It can be used for fat clients (i.e. Microsoft Outlook), thin clients (i.e. Citrix), or Web-based applications (i.e. Web Forms) and in most cases the applications themselves are not even aware that the organization has implemented an ESSO solution. There are definite advantages to implementing an ESSO solution in terms of flexibility. The drawback to ESSO solutions, however, is that software needs to be distributed, installed, and maintained on each desktop where applications are launched. Additionally, because the software resides on the desktop, there is no central location in which to determine if the user is allowed access to the application (authorization or AuthZ). As such, each application must maintain its own set of security policies.
The following diagram provides an overview of the steps performed in ESSO environments.

A user launches an application on their desktop. An agent running in the background detects a login screen from a previously defined template. If this is the first time the user has attempted to access this application, they are prompted to provide their credentials. Once a successful login has been performed, the credentials are stored in a credentials database. This database can be a locally encrypted database or a remote server (such as Active Directory). Subsequent login attempts do not prompt the user for their credentials. Instead, the data is simply retrieved from the credentials database and submitted on behalf of the user.
Container-Based Single Sign-On
Session information (such as authenticated credentials) can be shared between Web applications deployed to the same application server. This is single sign-on in its most basic and limited fashion as it can only be used across applications in the same container.
The following diagram provides a high level overview of the steps performed in container-based single sign-on environments.

A user accesses a Web application through a standard Web browser. They are prompted for their credentials which can be basic (such as username and password) or can utilize other forms of authentication (such as multi-factor, X.509 certificates, or biometric). Once the user has authenticated to the application server, they are able to access other applications installed in the same J2EE container without having to re-authenticate (that is, if the other applications have been configured to permit this).
Traditional Web Single Sign-On
In contrast, WSSO deployments only apply to the Web environment and Web-based applications. They do not work with fat clients or thin clients. Software is not installed on the user’s desktop, but instead resides centrally within the Web container or J2EE container of the Web application being protected. The software is often times called a “policy agent” and its purpose is to manage both authentication and authorization tasks.
The following diagram provides a high level overview of traditional Web Single Sign-On.
A user first attempts to access a Web resource (such as ADP) through a Web browser. They are not authenticated to the domain so they are directed to the central authentication server where they provide their credentials. Once validated, they receive a cookie indicating that they are authenticated to the domain. They are then redirected back to the original Web resource where they present the cookie. The Web resource consults the authentication server to determine if the cookie is valid and that the session is still active. They also determine if this user is allowed access to the Web resource. If so, they are granted access. If the user were to attempt to access another Web resource in the same domain (i.e. Oracle eBusiness Suite), they would present the cookie as proof that they are authenticated to the domain. The Web resource consults the authentication server to determine the validity of the cookie, session, and access rights. This process continues for any server in the domain that is protected by WSSO.
Portal or Proxy-Based Single Sign-On
Portal and proxy-based single sign-on solutions are similar to Standard Web Single Sign-On except that all traffic is directed through the central server.
Portal Based Single Sign-On
Target-based policy agents can be avoided by using Portal Servers such as LifeRay or SharePoint. In such cases the policy agent is installed in the Portal Server. In turn, the Portal Server acts as a proxy for the target applications and may use technologies such as SAML or auto-form submission. Portal Servers may be customized to dynamically provide access to target systems based on various factors. This includes the user’s role or group, originating IP address, time of day, etc. Portal-based single sign-on (PSSO) serves as the foundation for most vendors who are providing cloud-based WSSO products. When implementing PSSO solutions, direct access to target systems is still permitted. This allows users to bypass the Portal but in so doing, they need to remember their application specific credentials. You can disallow direct access by creating container-specific rules that only allow traffic from the Portal to the application.
Single Sign-On Involving Proxy Servers
Proxy servers are similar to PSSO implementations in that they provide a central point of access. They differ, however, in that they do not provide a graphical user interface. Instead, users are directed to the proxy through various methods (i.e. DNS, load balancers, Portal Servers, etc.). Policy agents are installed in the proxy environment (which may be an appliance) and users are granted or denied access to target resources based on whether they have the appropriate credentials and permission for the target resource.
The following diagram provides a high level overview of centralized single sign-on using Portal or Proxy Servers.
Federation
Federation is designed to enable Single Sign-On and Single Logout between trusted partners across a heterogeneous environment (i.e. different domains). Companies that wish to offer services to their customers or employees enter into a federated agreement with trusted partners who in turn provide the services themselves. Federation enables this partnership by defining a set of open protocols that are used between partners to communicate identity information within a Circle of Trust. Protocols include SAML, Liberty ID-FF, and WS-Federation.
Implementation of federated environments requires coordination between each of its members. Companies have roles to play as some entities act as identity providers (IDP – where users authenticate and credentials are verified) and service providers (SP – where the content and/or service originate). Similar to standard Web Single Sign-On, an unauthenticated user attempting to access content on a SP is redirected to an appropriate IDP where their identity is verified. Once the user has successfully authenticated, the IDP creates an XML document called an assertion in which it asserts certain information about the user. The assertion can contain any information that the IDP wishes to share with the SP, but is typically limited to the context of the authentication. Assertions are presented to SPs but are not taken at face value. The manner in which assertions are validated vary between the type of federation being employed and may range from dereferencing artifacts (which are similar to cookies) or by verifying digital signatures associated with an IDP’s signed assertion.
The interaction between the entities involved in a federated environment (user, SP and IDP) is similar to the Web Single Sign-On environment except that authentication is permitted across different domains.
A major difference between federated and WSSO environments involves the type of information generated by the authenticating entity to vouch for the user and how it is determined that that vouch is valid and had not been altered in any way.
The following table provides a feature comparison between Web SSO and Enterprise SSO.
| Features | WSSO / PSSO / Proxy | ESSO |
| Applications Supported: | Web Only | Web Applications and Fat Clients |
| “Agent” Location: | Target System | User Desktop |
| Technologies: | SAML, Form Submission, Cookies | Form Submission |
| Internal Users? | Yes | Yes (through portal) |
| External Users? | Yes | No |
| Central Authentication? | Yes | No |
| Central Authorization? | Yes | No |
| Central Session Logoff? | Yes | No |
| Global Account Deactivation? | Yes (through password change) | No |
We oftentimes view new technologies as providing us with the path back to Eden – that which returns us to leisure and care free living. Yet with each new technological improvement, our lives do not become easier, they are simply changed.














