Tuesday, August 10, 2010

Authentication and Authorisation

by Simon Biles

Simon Biles
About the Author

Simon Biles is a founder of Thinking Security Ltd., an Information Security and Risk Management consultancy firm based near Oxford in the UK.

Authentication and Authorisation (please notice the “s” is _not_ a spelling error!) are fundamental to information security – identifying who a user is (authentication), and what they are allowed (authorised) to do allow us to restrict access to data in such a way that only the rightful permitted people can access, modify or copy it. It seems in the current day and age, we have a habit of lumping the two together with the term “Identity and Access Management” – but personally, I think that it is wise to remember that they are separate and distinct processes, handled at different times and by different parts of the computer that you are using.

Let’s start off with Authentication – the “prove who you are” part. Authentication can be performed in certain ways – typically these are described as: something you know, something that you have or something that you are – each one of these is called a “factor” and, logically, combine two or more of them and you have “multi-factor” authentication. The password is an example of the first of these “factor” types, although there are other things, such as the questions you answer for your password reset (the name of your first pet goldfish, your favourite teacher at school, how many warts you have between your toes, that kind of thing). The things that you have are things like smartcards or dongles, whereas the things that you are include all of the biometric measurements – fingerprints, voice recognition and the like. Each of them has their inherent issues – people forget things, lose things, and, rather frighteningly, people can have bits of them taken – numerous examples abound in film – “Angels and Daemons” springs to mind as the most recent, but I recall “Thunderball” also makes use of the concept.

However, by far the most common, cheapest and familiar form of authentication is the password. Passwords are something that are now ubiquitous – if you have a computer & an internet connection, you have a password. Most operating systems implement them in some form now by default, usually for elevation of privileges to an administrative account - those of us that have been using UNIX or its derivatives for the last few decades (or indeed some earlier multi-user operating systems) can all have a good laugh now and congratulate Microsoft and Apple for having caught up. They’ve been around a lot longer than that though, I did a little research and I could certainly find written references as to the use of passwords as far back as the Roman legions, and I’ve every confidence that they were in use well before that in some form or another. The Roman implementation of passwords was exemplary though, and, quite frankly, something that many modern password implementations could learn from – controlled distribution, frequent changes and traceability of distribution. If you are interested there is more to be found here (wordinfo.info).

The commonality of passwords has created a unique problem (and opportunity from a Forensic viewpoint) that people have terrible memories for things, especially where there is little in the way of context to give them a clue, so they tend to use the same password multiple times. Where, as professionals, we have the capability to enforce certain technical restrictions on the user (password length and complexity requirements, change durations, non-repeatability etc.) we quickly find that the user subverts the process one way or another – the most ubiquitous being the dreaded post-it note! I’d like to draw your attention to the “professional” intelligence agents operating until recently in the US, a 27 character password, having been committed to memory could have been a significant issue for the Forensic Officers, however, having it written down alongside the computer … well, need I say more ?

Read more at http://www.forensicfocus.com/simon-biles

No comments: