Passwords And Why They’re Going Nowhere

Passwords have been the bane of security implementers ever since they were introduced, yet still they are present on nearly every app, website and system in use today.  Very few web based subscription sites use anything resembling two-factor authentication, such as one-time-passwords or secure tokens.  Internal systems run by larger organisations implement additional security for things like VPN access and remote working, which generally means a secure token.


Convenience Trumps Security

Restricting access to sensitive information is part of our social make up.  It doesn't really have anything to do with computers.  It just so happens for the last 30 years, they're the medium we use to access and protect that information.  Passwords came before the user identity and were simply a cheap (cost and time) method of preventing access to those without the 'knowledge'.  Auditing and better user management approaches resulted in individual identities, coupled with individual passwords, providing an additional layer of security.  All sounds great.  What's the problem then?  Firstly users aren't really interested in the security aspect.  Firstly, users aren't interested in the implementation of the security aspect.  They want the stuff secure, they don't care how that is done, or perhaps more importantly, don't realise the role they play in the security life cycle.  A user writing down the password on a post-it is a classic complaint of a sysadmin.  But the user is simply focused on convenience and performing their non-security related revenue generating business role at work, or accessing a personal site at home.


Are There Alternatives & Do We Need Them?

The simple answer is yes, there are alternatives and in some circumstances, yes we do need them.  There are certainly aspects of password management that can help with security, if alternatives or additional approaches can't be used or aren't available.  Password storage should go down the 'hash don't encrypt' avenue, with some basic password complexity requirements in place.  Albeit making those requirements too severe often results in the writing down on a post-it issue...

Practical alternatives seem to be few and far between (albeit feel free to correct me on this).  By practical I'm referring to both cost (time and monetary) and usability (good type-I and type-II error rates, convenient).  So biometrics have been around a while.  Stuff like iris and finger print scanning as well as facial recognition.  All three are pretty popular at most large-scale international airports, mainly as the high investment levels can be justified.  But what about things like web applications?  Any use of biometric technology at this level would require quite a bit of outlay for new capture technology and quite possibly introduces privacy issues surrounding how that physical information is stored or processed (albeit hashs of the appropriate data would probably be used).

There are also things like one-time-passwords, especially using mobile phones instead of tokens.  But is the extra effort in deployment and training, enough to warrant the outlay and potential user backlash?  This would clearly boil down to a risk assessment of the information being protected, which the end user could probably not articulate.


Why We Still Use Them...

Passwords aren't going anywhere for a long time.  For several reasons.  Firstly it's cheap.  Secondly it's well known by developers, frameworks, libraries, but most importantly the end user.  Even a total IT avoider, is aware of the concept of a password.  If that awareness changes, there is suddenly an extra barrier-to-entry for your new service, application or website to be successful.  No one wants that.

Thirdly, there are several 'bolt on' approaches to using a username and password combination.  Thinking of things like step-up authentication and knowledge based authentication.  If a site or resource within a site is deemed to require additional security, further measures can be taken that don't necessarily require a brand new approach to authentication, if a certain risk threshold is breached.

As familiarity with password management matures, even the most non-technical of end users, will become used to using passphrases, complex passwords, unique passwords per applications and so on.  As such, developers will become more familiar with password hashing and salting, data splitting and further storage protection.  Whilst all are perhaps sticking plaster approaches, the password will be around for a long time to come.

By Simon Moffatt


Optimized Role Based Access Control

RBAC.  It's been around a while.  Pretty much since access control systems were embedded in to distributed operating systems.  It often appears in many different forms, especially at an individual system level, in the form of groups, or role based services, access rules and so on.  Ultimately, the main focus is the grouping of people and their permissions, in order to accelerate and simplify user account management.


Enterprise RBAC
Enterprise role management has become quite a mature sub-component of identity and access management in the last few years.  Specialist vendors developed singularly focused products, that acted as extensions to the provisioning tooling.  These products developed features such as role mining, role approval management, segregation of duties analysis, role request management and so on.  Their general feature set was that of an 'offline' identity analytics database, that could help identify how users and their permissions could be grouped together, either based on business and functional groupings or system level similarities.  Once the roles had been created, they would then be consumed either by a provisioning layer, or via an access request interface. The underlying premise, being that access request management would be simplified due to business friendly representations of the underlying permissions and the account creation and fulfillment process would be accelerated.

The Issues & Implementation Failures
The process of developing an RBAC model was often beset with several problems.  IAM encompasses numerous business motives and touch points - which is why many still argue identity management is a business enabler more than a security topic - and developing roles across multiple business units and systems is time consuming and complex.  A strong and detailed understanding of the underlying business functions, teams, job titles and processes is required, as well the ability to perform analysis of the required permissions for each functional grouping.  Whilst this process is certainly mature and well documented, implementation is still an effort laden task, requiring multiple iterations and sign off, before an optimal model can be released.  Once a model is then available for use, it requires continual adaption as systems alter, teams change, job titles get created and so on.  Another major issue with RBAC implementation, is the often mistaken view, that all users and all system permissions must be included in such an approach.  Like any analytic model, exceptions will exist and they will need managing as such, not necessarily be forced into the RBAC approach.

Speeding up Role Creation
Role creation is often accomplished using mining or engineering tools.  These tools take offline data such as human resources and business functional mappings, as well as system account and permissions data.  Using that data, the process is to identify groupings at the business level (known as top down mining) as well as identifying similarities at the permissions level (known as bottom up mining).  Both processes tend to be iterative in nature, as the results are often inconsistent, with difficulties surrounding agreement on user to functional mapping and of function to permissions mapping.

One of the key ways of speeding up this process, is to use what is known as 'silent migration'.  This approach allows roles to be created and used without change to the users underlying permissions set.  This instantly removes the need for continual approval and iteration in the initial creation step.  The silent migration consists of initially mapping users into their functional grouping.  For example, job title, team, department and so on.  The second step is to analyse the system permissions for users in each functional grouping only.  Any permissions identified across all users in the grouping are applied to the role.  No more, no less.  With it, no changes are therefor made to the users permissions.  This process is simply performing an intersection or each users' permissions.

Focus on the Exceptions
Once the users of each functional grouping have had their permissions migrated into the role, it's now important to identify any user associated permissions that are left over.  These can simply be known as exceptions, or permissions of high risk.  They're high risk, as they are only assigned to specific individuals and not the group.  This association could well be valid - a line manager for example may have different permissions - but as a first pass, they should be reviewed first.  To identify which are exceptions, a simple subtraction can be done between the users current permissions (as identified by their target system extract) and the permissions associated with their functional grouping.  Anything left needs reviewing.

This approach can also help with the acceleration of access review strategies.    Instead of looking to review every user, every permission and every functional grouping, simply analyse anything which is anomalous, either via peer comparison or functional grouping.

RBAC is a complex approach, but can provide value in many access review and access request use cases.  It just isn't a catch all, or perhaps approach for every system and user.  Specific application using a more simplified approach can reap rewards.

By Simon Moffatt