I was asked today by a board member to respond to a question from a prospective investor who wanted to know how Live Ensure (our service) differed from two other – lets call them ….the more traditional solutions.  For the sake of this blog we will call them the Old and the New solutions.  

Let me describe the Old Co solutions to you briefly.  They both embody technologies which are over a decade old ( think RSA ) such as tokens and servers ( both physical and virtual).  Their solutions rely on the user entering a PIN into a browser and thereby satisfying the ‘something you know ‘ part of strong authentication.  

Here it is slightly edited.

The biggest weakness of both Old Co solutions are the vulnerability to MITM and MITB attacks.

Both require the user to enter a PIN ( something you know ) ie a second factor over and above the user name and password ( the single factor or weak authentication ).

The user enters this PIN back into the browser which is as yet not secure and so vulnerable to interception.    See extract from Old Co 1 site : “  In this  mode the user is presented with their challenge (security string) in the same channel that they will enter their response (one-time-code).  This is generally implemented within a browser. “

Here the user is required to ‘generate’ their PIN by picking out from a string of digits presented their PIN number based on a pre-agreed arrangement / image / layout.  “ The user combines their PIN in their head with the security string and enters their OTC within the login screen. “   ( Big opportunity here for user failure and calls to a support centre)

This is classified as ‘ security by obscurity’  because the two parties are in effect comparing a shared secret.    There is no way that the site can determine with 100% accuracy that the person on the other side is the person who they claim to be  - just that they know the answer to the question.  This is the failure of most 2FA solutions today.   A hacker sitting in any Eastern Europe country can satisfy the requirements of the site.    This is impossible with Live Ensure (New Co).  

• Both Old Co solutions use the browser to convey their PIN (secret) – Live Ensure does not hence immune to MITM and MITB attacks.     

Live Ensure is a true SAAS and is able to be integrated into any log in form including all of those covered by both solutions as well as many more.   These solutions are limited in their ability to scale because of their manifestation  (Appliance servers – both physical and virtual )
Extract from Old Co 1 site “ Old Co service is highly scalable with each appliance capable of supporting in excess of 250,000 active users. “    This against Live Ensure which can scale instantaneously to millions of users as quickly as they can enroll.

Old Co 2’s  ability to scale is limited by virtue of its use of tokens.   Here every user needs to be provided with a token be it physical or virtual.   The shortcomings of tokens are well documented.   Expensive,  easy to lose,  they are static ( they end up in the hands of the ‘user’ whether legitimate or not ),  their seed is hackable  (RSA).

• Both Old Co’s are difficult to scale.   Live Ensure strength is its ability to scale exponentially without any impact on performance.      

Live Ensure is available as a mash up integration from the Web portal.   There are no professional services nor System Integrators required to install the solution.   This is not the case with either of the Old Co’s.    In fact just to get a demonstration you have to write to someone at the company.  With Live Ensure you just go to the App store download the App and then go to the website where a demo can be done instantaneously.

• Both Old Co’s products are cumbersome for the Enterprise or site to get and integrate into their site.   Live Ensure is a true SAAS and can be integrated into a site or application within hours by a capable developer.  

The pricing for the Old Co 1 solution is not transparent.  What is clear is that it consists of a licence fee plus a hardware/ appliance fee plus a maintenance fee.    The Old Co 2 solution is also vague on pricing but given that it needs to cover the cost of tokens will be pricier than Live Ensure.

• Live Ensure pricing is very clear and simple.    It is priced either on a per user per annum basis or on a per authentication basis.   As a true SAAS the pricing which includes all maintenance and software upgrades will be cheaper than either of these solutions.   Which also require a support / customer centre in order to operate.   (At what cost ?) 

Live Ensure is a lightweight,  transparent,  tokenless,  SAAS solution that can be implemented across enterprises and websites with equal efficacy.    It leverages the device that users already have – a mobile phone and requires no ‘heavy-lifting’ on the part of the user.  No PIN/Pattern to remember (first point of weakness of these solutions ) .

Both Old Co’s are enterprise focused (could never be implemented across a large website ),  require extensive IT department involvement both initially and on an ongoing basis,  and the technology is at least a decade old.  There is nothing new or innovative here.    Their only strength is their legacy and like RSA will soon be supplanted by faster moving, disruptive and importantly more secure solutions.    These solutions are basically just fancy PIN generators – just a variation on user name and password.  

Live Ensure is streets ahead in terms of its use of  context for authentication (ensuring the right parties are present in order for authentication to be possible) as well as the strength of geo factors and behavioural factors now possible with smart-phones.    This is called defense in depth and is in direct contrast to the security by obscurity advocated by both Old Co solutions.     A big failing.

Out with Old and in with the New ?

Mary Meeker informs us that there are now 1.1bn  Smartphones  (17% of all mobile phones) and these are driving Internet growth with a total of 2.4bn people now connected to the Internet.

Mary Meeker Internet trends

The universe for hackers just grows and grows.    One of the most lethal of these attacks is Zeus (ZITMO) – which is aimed squarely at Smartphones.

The Zeus attack is an example of several attacks now being launched that are based wholly on anticipated behavior, especially as it relates to social media, single-sign-on and BYOD.

A sophisticated Zeus campaign stole an estimated €36 million, or $47 million, from over 30,000 customers across more than 30 banks in Europe this summer.

The Eurograbber campaign, as it has been named, used custom versions of Zeus and Zeus in the mobile (ZITMO) Trojans to bypass the two-factor authentication measures to compromise customer bank accounts, Darrell Burkey, director of IPS products at Check Point Software Technologies, told SecurityWeek.  The attack intercepted SMS messages sent to customers to confirm financial transactions.      Zeus campaign


The attack is successful on Android, since that is an open platform.   Not successful on iOS, since it is not.

The main approach is to triangulate something happening on a computer (PC/laptop tablet)  with something happening on the phone.  A One Time Password (OTP) is sent to the phone via SMS.    An API exists on the phone that allows interaction with SMS -  and so this data can be forwarded to the hackers own device where he can log-in ‘as the user’  - even though he may be thousands of miles away.  

This attack is merely a capture and replay attack, just focusing on grabbing the disparate OOB elements and marrying them "out of context".    The site knows no better because it is expecting the correct OTP to be presented – and it is.  The site has no idea where it is coming from.   (This is true of all such OTP solutions relying on ‘secrets’ being sent back to the site.)

This attack is not trivial but it is preventable.  By LiveEnsure®– here is why:

a) The LiveEnsure® flow is reversed.  Hackers cannot initiate a login and then snag an SMS from the phone when sent and apply it themselves.
b) LiveEnsure® doesn’t use SMS at all – LiveEnsure® relies on email and then only for registration - which this attack (by design) must happen after registration to work.
c) The LiveEnsure® agent is impervious to Trojans - on any platform - since it is a dynamic event in a separate memory space from the browser or calling application  (or  Trojan for that matter)
d) With LiveEnsure® nothing is sent from the app or phone to the site, which means anything the hacker steals cannot be used back at the site, it has to be used on the phone which they don't have.
e) What is used on the phone is not sent back to the site for verification, it is sent to LiveEnsure® - which only expects what it expects, and cannot be fooled by captured information (from a fragile channel)

f) That is why LiveEnsure® measures ‘location’ - if the hacker and the real user are not standing side by side in front of the screen…... then whatever they might steal (but cannot anyway) would be contextually invalid.

LiveEnsure® is about context, not credentials.   This attack is merely a capture and replay attack, focusing on grabbing the disparate OOB elements and marrying them "out of context".

It's exactly what LiveEnsure® is designed to thwart.

Not a good week for NatWest innovative banking services. 

NatWest Get Cash fraud  (Get Cash Pulled)

A combination of a simple phishing attack and a fundamentally insecure service led to many users of the Get Cash service ( a sub set of the NatWest mobile banking app – powered by Monitise) being defrauded of cash from their accounts.   

The system allows users to get cash from an ATM by keying in a ‘secure cash code’ into the terminal.    The assumption is that once you have logged in to your app you are legit and so you ping the system for the code.   A user name and password level of security – that’s it!.   No better than 99% of all apps on the Net today.   

Needless to say the service was shut down once the fraud started becoming rampant.   

Does the drive for customer convenience completely outweigh basic security rules. ?   The problem with this kind of solution and others that rely on the presentation of self reported credentials i.e. user name and password are that these stateful artifacts are vulnerable to interception and re-use by a non-legitimate party i.e. the hacker, in this case through a phishing attack.  The system does not know that the credentials being presented are being done so by the ‘wrong’ person.   

Any security system worth its salt (pun intended) thus needs to rid itself of the baggage of years and years of ‘traditional’ security solutions such as certificates, tokens, java-script scraping, cookies passwords, keys and OOB.  All shared secrets - incarnations of ‘security by obscurity’.  (The problem with Passwords ) (The end of passwords)

Modern day hackers can crack passwords in seconds and bypass the defences laid by these solutions.   The conundrum for CIO’s and CSO’s is to find the balance between usability and efficacy.   As I stated in a previous blog – I am sure that most sites and custodians of your security are actually indifferent to your privacy and your security, hence the weakness of the solutions implemented.   Here is an example of just how weak the ‘latest’ technologies are :  
(The failure of RFID ) 

Imagine if there were solutions that harnessed the ubiquity of SSO’s but were also strong in the 2FA sense.   In order to have universal appeal new solutions need to work in the BYOD / mobile domain.  No more needs to be said about the proliferation of smart mobile devices.   Effective solutions need to be easy for decision-makers to get and try out.  Gone are the days of lengthy POC’s and trials.   In the same way that consumers can try out tracks on iTunes and return unwanted products to sites like Zappos,  so security solutions should  be as easy to try out for free and get if they work and cancel if they don’t.   I think that professional services will take a big hit in the enterprise arena.   No longer required with SAAS. 

We have already seen RSA take a big hit last year when its own defences were breached.   We are now at the stage that the Lance Armstrong’s of the security industry (i.e. those who have pulled the wool over the eyes of their customers for many years ) are going to be exposed as their solutions fail on an ever increasing basis.   

It is time for security to come clean.  Only those solutions that are truly innovative will succeed.   When someone like the founder of Wikipedia says that a security failure could bring down a company like Facebook  (Security breach could bring down Facebook) maybe its time to wake up. 

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).

The breach at RSA just goes to show that security by obscurity never works.

And you are probably wondering just what is ‘security by obscurity’ ?

Lets use a simple metaphor that is familiar to us all to help explain the concept.

We have all at one time or another left a spare key under the doormat, just in case we are locked out of the house, or we leave it for someone else to use to get in.   Well,  simply put, that is - security through obscurity.

The theoretical security vulnerability is that anybody could break into the house by unlocking the door using the spare key from under the mat.    Add to that scenario the reality that any burglar worth his salt will check out the most obvious hiding places, and so we, the house owner, run a  greater risk of a burglary by hiding the key in this way, since the effort of finding the key is likely to be less effort to the burglar than breaking in by another means. We have in effect added a vulnerability  (the fact that the key is stored under the doormat) to the system, and one which is very easy to guess and exploit.

In the case of computer code or RSA algorithms the assumption is that the algorithm cannot be broken – that the burglar wont find the key under the mat.  Alas we have just found out how fatally flawed that logic is.  And boy it could not have happened to more iconic an institution than RSA.   The very same RSA that invented the public and private key algorithm (based on factoring of primes) that has formed the foundation of Internet security for the last 25 years.   But at the end of the day it is still security by obscurity.  

Enter Kerckhoff and his principle.  http://en.wikipedia.org/wiki/Auguste_Kerckhoffs
http://artofinfosec.com/335/crypto-kerckhoffs-principle/

 “ Assume your enemy has the details of your system “

If your security relies on some level of operational system "secrecy" to work, it is just a matter of when, not if, the system will be compromised. The problem with traditional shared secret tokens,  (not to mention cost, deployment and custody issues)   is that they do nothing to establish context of the mutual authentication i.e. the establishment of trust between the parties.    They are merely additional layers of "secret passwords", regardless of how those factors are generated or delivered.    http://www.schneier.com/crypto-gram-0205.html


The application most used by the RSA SecureID token, being the generation of a “One Time Password”  which is then entered into the browser;   is reliant upon the integrity of the browser,  the very vehicle  for which trust has not yet been established.   This constitutes a fatal flaw in the ‘design’ of the system.

The primary issue involved in this breach is the wide applicability of the "secret" elements that were compromised. In a properly architected authentication system, any security failure should be at worst, a one-in-a-row event.  In this case – assuming the hackers indeed have succeeded in ‘stealing the password’  ( the seed to the key generator)  they can exploit the vulnerability of all of RSA’s customers.   Not just one or two.

Being the ‘chosen’ security vendor to  “  90% of the Fortune 500 “  ( per RSA’s website)  leads to hubris and hubris leads to complacency.  The World now operates at Internet speed.  Just ask the Tunisian and Egyptian ( and who knows more) Governments about that.    No one can assume that their position is safe.  The rise of Hacktivism (http://bit.ly/gcqhxe) means that security has now risen right up the agenda and for RSA to be seen to be stumbling at such a crucial time could prove to be very damaging.    

Fortunately there are nimble and agile upstarts like http://www.liveensure.com who are showing the industry that innovation is alive and well and that solutions (that work) are available and they are affordable too.