Authentication in ' context'

con·text/ˈkäntekst/

The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.

authenticate [ɔːˈθɛntɪˌkeɪt]
vb (tr)
 to establish as genuine or valid

What does context have to do with authentication?

When you log on to a web site and enter your user name and password so as to ‘authenticate’ yourself all you are presenting are self reported credentials to the site.  If you present the correct credentials then the site accepts you as - who you say you are.   It takes you at face value.  It identifies you.  Liken it to a knight of old arriving at castle and announcing himself.   When you log on to a web site and it asks you to log in with a user name and password – you are in effect – announcing yourself – identifying yourself.  

What happens if someone steals your password?   Then they can log on as you – the site is none the wiser – the thief has presented the correct credentials.  The credentials  are by definition – static.   They remain valid whether you do so from one of many devices unless of course the site is using a device recognition credential – a cookie,  a Javascript based device identification or certificate solution.    But again that credential is also static as it is re-used again and again no matter what the ‘context’.

A hacker can harvest your credentials by one of many methods be they social engineering, key logging, Trojans,  Man in the Middle or Browser  attacks and so on.  The hacker can re-use those credentials in a different ‘context’ (e.g. from another device in another country) but still be regarded as ‘valid’ by the site.

This is where most so called authentication solutions even two factor authentication solutions fail.   They ‘work’  irrespective of the context.  Even when an OOB OTP is sent via SMS and the PIN is entered into the browser the same vulnerability exists.  A hacker can intercept the PIN and replay the session in real time posing as the ‘real’ person.  In other words the OOB pin can be used on a different browser or even session, device or IP address from which they were requested.   In other words – a different context.

So why is context so important.?   Context is a function of three elements:

• time (i.e. the moment of authentication – when it happens, the session  ) ;

• Method/mode is the context of origination and transmission – things that dial into the location of the source i.e. the device.   Hence the popularity of some device based solutions.  Most of which fail because they rely on persistent data ( cookies or Javascript or  downloaded software ) because they are easy to fool or copy.

• Meaning is the literal value, or meaning of the credentials.  This is usually the total sum of the traditional login:  User name and password;   sometimes ‘beefed’ up perhaps with a time element (timeout) and source (ssl handle, cookie).    This is the value of the token or OTP/OOB, the value of the challenge response, etc., i.e. the "thing you know".   The site controls the value, the user must know it, get it and repeat  it back.  ( A shared secret ) which is usually the only unique element to the mix, as the other two are re-used, or known.

The timing of the event is important because the session commences only when all of the key players/participants in the authentication puzzle come together in context  for the act of ‘authentication’.   The key constituents are: the user,  the device,  the site and  the session.

Only when all of these parties (the correct /valid parties) come together i.e. in the right context - can true authentication take place.  None of these elements or even values associated with them like U/P, cookies,  JVscript  fingerprint or certificate should be able to be used in isolation in another session.  In other words in another context differentiated by time or device.  They all need to come together dynamically and uniquely for each session ( context)  to ensure integrity.

So a proper authentication solution is one where all elements (and more) are combined into a single context - whereby any of the elements in isolation, or out of context, are meaningless. In addition any element inspected in isolation should not be the key to unlocking or accessing (or guessing) any of  the others. They should be dissociative.

Finally none of the elements from this or any other context are re-used, at least in their native form.   It's okay to re-use a password, or re-challenge the device , but it has to be different by nature of it's membership in the context, and not meaningful outside of that (which is the source for most MITM, MITB, social engineering, phishing/ pharming, etc).