How to succeed in your professional endeavors

1. Think consciously.
   Say what you think.
   Do what you say.
   Show that it works through the things you do.
   



2. Never forget the golden 80/20 rule.


3. Especially remember:
   

   The idea and inception are about 20% of the way;
   80% of it are about making the idea a reality.

   
   

Nobody is perfect, so maybe it doesn't always work out all the time. Nonetheless, the important thing is to continue the intent to make it work.

About safety and security

Last year I have been invited to visit ABB Corporate Research and Development (Baden-Dättwil, Switzerland) for a job interview day. The job offering I applied to was CH1982, "R&D Scientist (PhD) Software Architecture / IT Security".

After some thinking on the topic, I decided to give a talk about OSGi, which is:
1) related to a part of my PhD thesis, especifically the implementation part;
2) all about software architecture; and
3) allowed me to mention and point out various security related aspects.

I personally think it was a pretty interesting presentation, even if most of the audience didn't perceive it as interesting at all. Although neither myself nor them felt that I was the right match for the job in the end, the visit was a really interesting experience.

Nonetheless, I left Switzerland with a renewed impression that:
1) "security" is often confused with "safety"; and
2) the use of the term "security" in IT is often not clearly linked to understandable concepts.

I originally planned to write a single installment on these two issues, from my point of view. Nonetheless, in the end, the second section grew too much to fit in here. Thus, I will share first some of my thoughts about 1) and then in later on blog about the various aspects of 2).

Enjoy reading, and you are welcome to leave your comment.

What is safety, what is security and what's the difference between them?

Webster comes up with useful definitions for safety:

1: the condition of being safe from undergoing or causing hurt, injury, or loss
2: a device (as on a weapon or a machine) designed to prevent inadvertent or hazardous operation

Also does Wikipedia:

Safety is the state of being "safe" (from French sauf), the condition of being protected against physical, social, spiritual, financial, political, emotional, occupational, psychological, educational or other types or consequences of failure, damage, error, accidents, harm or any other event which could be considered non-desirable. This can take the form of being protected from the event or from exposure to something that causes health or economical losses. It can include protection of people or of possessions.

Likewise, Webster provides some useful definitions for security:

1: the quality or state of being secure: as a: freedom from danger : safety b: freedom from fear or anxiety
4 a: something that secures : protection b (1): measures taken to guard against espionage or sabotage, crime, attack, or escape (2): an organization or department whose task is security

Also does Wikipedia:

Security is the condition of being protected against danger or loss. In the general sense, security is a concept similar to safety. The nuance between the two is an added emphasis on being protected from dangers that originate from outside. Individuals or actions that encroach upon the condition of protection are responsible for the breach of security.

As the Wikipedia text points out in the entry about security, the word "security" in general usage is synonymous with "safety. However, there is a subtle difference, that is also pointed out correctly in the same entry:

The nuance between the two is an added emphasis on being protected from dangers that originate from outside.

I will try to put it in an example:
Think of the spikes on the following photo (Wikimedia, Public domain):

Obviously, they provide some form of security for the people inside, but they are definately not safe for those trying to get in, as correctly pointed out by the warning sign.

So the difference between safety and security is maybe subtle, but very important: if you don't believe or understand, just try to climb one of those......

Stay tuned for a security concepts follow up :)

Sunset

Sunset,
originally uploaded by Dieter Wimberger.

Just wanted to share this view with you.

It's a mapped HDRI image (created from 13 images), but it represents pretty much what I just presenced on the roof of my building :)

Enjoy :)

Elmo in Action

After enjoying some of the heists at MacHeist II, I have recently acquired their software bundle :)

I decided to have some fun and followed the call from definetheline to create and post something we have done with the software (iStopMotion).

So here you go:


If you are looking for some software, visit, check out and buy their bundle, if you like what is in it :)

If you do, buy from here.

OAuth is NOT about authentication

I am still trying to figure a way through the jungle of web security stuff that is brewing on the web lately. Maybe I get it all wrong, but sometimes I just miss the point where people think it is most obvious.

This time I am really puzzled by OAuth.

When I stumbled over it I began reading the available resources, from the home page to the Getting Started document and finally all of the OAuth 1.0 core specs.

OAuth is repeatedly claimed to be about authentication:

an open protocol to allow secure API authentication in a simple and standard method from desktop and web applications
(OAuth home page, promised right upfront top)

More generally, OAuth creates a freely-implementable and generic methodology for API authentication.
(OAuth Core 1.0 Specifications, Abstract)

So far so good....what puzzles me so much is the fact that according to my understanding of authentication, OAuth isn't about authentication at all.
But decide yourself:

I consider authentication a well defined security concept:
Authentication

Authentication (from Greek αυθεντικός; real or genuine, from authentes; author) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying their identity. Authentication depends upon one or more authentication factors.

So here is what one would expect from OAuth if it would be about authentication, based on their own example:

A typical example offered by the spec (Appendix A) is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.
(OAuth Getting Started)

I take the freedom to reduce this to the following use case:


Which I resumed as follows:

1. The user wants to print an image using a print service.


2. The print service should get the photo on behalf of the user from the user's photo service.


3. The user should be able to authorize the print service to get the photo, without having to expose the credentials of the photo service to the print service.

So let's see where we need authentication in this use case:

1. Between user and print service


2. Between user and photo service


3. Between print service and photo service

So far so good. What one would expect is that OAuth is "somehow" about these three points (or part of them).

But surprise. Here is what the OAuth 1.0 core specs state:
1)

OAuth authentication is the process in which Users grant access to their Protected Resources without sharing their credentials with the Consumer.
(OAuth Core 1.0 Specifications, 6. Authenticating with OAuth)

2)

The Service Provider verifies the User’s identity and asks for consent as detailed. OAuth does not specify how the Service Provider authenticates the User.
(6.2.2. Service Provider Authenticates the User and Obtains Consent)

and:

When displaying any identifying information about the Consumer to the User based on the Consumer Key, the Service Provider MUST inform the User if it is unable to assure the Consumer’s true identity. The method in which the Service Provider informs the User and the quality of the identity assurance is beyond the scope of this specification.
(6.2.2 Service Provider Authenticates the User and Obtains Consent, last paragraph)

From my point of view, and the well established definition of authentication:

1) is a total contradiction, or at best a re-definition of authentication, to another well defined security concept, namely authorization:
Authorization

In security engineering and computer security, authorization is the concept of allowing access to resources only to those permitted to use them. More formally, authorization is a process (often part of the operating system) that protects computer resources by only allowing those resources to be used by resource consumers that have been granted authority to use them. Resources include individual files' or items' data, computer programs, computer devices and functionality provided by computer applications. Examples of consumers are computer users, computer programs and other devices on the computer.

2) states clearly that OAuth is not concerned with authentication between the user and the service.

3) states clearly that OAuth is not concerned with authentication between the services (consumer and provider).


So, maybe I am missing the point totally, or OAuth isn't about authentication at all.