Anatomy of Passwords

January 2nd, 2014 at 12:33 UTC by Dan Cvrcek

Passwords have not really changed since they were first used. Let’s go down the memory lane a bit and then analyse how password systems work and how they could be improved. You may say – forget passwords, OTP is the way forward. My next question would then be: So why do we use OTP in combination with passwords, when they are so good?

My Memory Lane

I remember reading research reports about password insecurity in early 90s as an undergraduate student. I downloaded them with gopher, on green terminals and printed some of them on my home-made “ballpoint pen plotter”.

A lot has changed, now we have “the cloud”, again. Kids have mobile phones with memory many times bigger than disk of my first computer. Still, passwords are the same, except there are many more of them.

We started using variations of old passwords – mostly less secure but they are “different”. Entering 3 letters out of 8 (and it must be 8 because 9 would make the system unusable) does not sound like better security to me. It gives 1 in 4,000 chance to guess the right password (see character probabilities in section Local Counts by Position Within Word). But it is different is it might improve security.

Enterprise-grade security uses one-time passwords. The level of security provided by OTP is rather poor (1:1,000,000). One can compare that to my first password generated in 1993 – 8 lowercase letters and digits – with 41 bits of entropy (chance of random guessing is 1:1,000,000,000,000). This password would even do as a decent encryption key at the time. Computers are simply faster, we are just older.

Good and Bad

Passwords can be incredibly secure and powerful as an authentication mechanism. Encryption keys are used by everybody who wants to protect their data. The only difference between passwords and encryption keys is that passwords use only symbols from ASCII table to easier typing. A good password can be as secure or even more secure than keys protecting our credit card transactions.

When we say secure we mean hard to guess. Unfortunately that is not good enough. Much more important is how and where we use the key or password. NSA or GCHQ will not try to guess your password as it does not scale very well, they will try to simply read it when you use it.

What we need to solve to make things better are two main password problems:

  • users choose weak passwords that are “easy” to guess; and
  • passwords are easy to compromise as we have to type them time after time.

The trouble with passwords is in the huge “attack surface”. The opportunity for attackers to eavesdrop our passwords in transit or when typed to a computer is enormous. On the other hand, how much time is needed to launch a successful attack – does one need a week or just a few seconds to exploit stolen passwords? How much value is in decreasing the password validity interval from 30 days to 30 seconds?

Security experts often say that we should choose secure passwords and change them frequently. That is all jolly good but … we just begin relying on email reminders and end up with an email “password management” or call IT support more often when connecting to work computers and networks.

The main strength of passwords is that we can just type them and they work with almost any computer system. Replacing passwords with something else means change, and change hurts. We can argue how much pain are users willing to accept and then figure out how more secure can passwords be.

Authentication Is …?

The whole point of authentication is to compare two values. One is computed by a server, the other should ideally involve the user.

Authentication can be based on users providing values they have at hand, or values they receive from servers (different channels for receiving and sending are preferable, or users should do a value transformation).

Traditionally we say that authentication is based on something we know, something we have or something we are. Practically:

  • what we are does not change – once compromised, it is compromised forever and becomes useless for anything even remotely connected to computers;
  • what we know – is usually so weak that it provides poor security and is again not very good for computers today.

We end up with “something we have”. However, I don’t think it means that passwords are history. There is nothing in the definition of “password” that would say you have to remember it.

Password Threats

The most visible threat to passwords is a large password leak from one of the big servers. This is used to justify all sorts of novel authentication solutions. While the fix is fairly simple and completely transparent to users. All that needs to be done is to protect passwords with a keyed cryptographic function – e.g., HMAC, or even just symmetric encryption.

One of the options is to use a hardware device with a simple API (we have developed Scramble SCrib and a remote API for its use). The form factor of such a device is insignificant, the important thing is the ability to introduce a simple API that will protect the cryptographic key.

Unfortunately, there are more security threats to passwords.

What we want to achieve is a significant improvement of password security with as little change to the authentication system as possible. The following picture shows what a password authentication system can look like.

  • Users can use tools so that they don’t have to remember their passwords – this means that passwords are truly unguessable.
  • Computer hardware can be extended to “hide” real passwords from users (or their naughty friends) and/or facilitate use of user tools.
  • Computer software can again be extended to provide any new functionality required to interact with Application or Authentication server.
  • Application server normally just forwards data from users to its authentication module or an external server but it can execute an additional transformation.
  • Authentication server actually verifies user credentials and its database stores passwords.

Each part of the system is sensitive to different threats. That gives us opportunity to mitigate threats that we worry about. We can show some examples where we protect particular parts of authentication system and hence mitigate relevant threats.

  • If we push a new “password” to Authentication Server after each authentication, we get a one-time password system that is much stronger than today’s OTP systems.
  • If application server “decrypts” credentials received from User, we could still have a password-based authentication system but passwords are cryptographically protected between User Tool and Application Server.
  • Computer Software could do a password transformation instead of the back-end application server to limit system changes. A scenario suitable for corporate environment where end-points (e.g., laptops) are reasonably locked-down.



We can choose how much pain we can absorb and create a system that is still password-based (in its core) but much secure than today’s passwords. Passwords are dead – say many. No they are not, they will stay for a while, although they may become more secure.

You can read more in a paper presented in Prague’s Santa Crypto and a presentation.

Entry filed under: Authentication, Protocols, Usability, Web security

7 comments Add your own

  • 1. Kaz Augustin  |  January 6th, 2014 at 08:21 UTC

    Hi Dan. Here’s a question that’s been bugging me for years. Let’s say I have discrete passwords for each website I authenticate at. I also pick a complicated 10- to 15-character password that includes upper- and lower-case letters, numbers and symbols.

    Security “experts” tell me that I need to change my password often. But why? If it’s very strong, what’s the utility in changing it, especially when I’m not aware of it being hacked?

    If I change my password every, say, 30 days, there’s still a window of 1 to 29 days when an attacker can take advantage of my “old” password and, as we know, email-password combinations are spruiked very quickly. In real terms, is there really an advantage in coming up with unrelated, complicated passwords every 30 days?

  • 2. Peter  |  January 6th, 2014 at 12:51 UTC

    Security experts have been saying for years that forced password aging is little use.

    Fred Piper was first I think in 1997.
    http://all.net/Analyst/netsec/1997-09.html
    Spaf, Ross and Bruce have all said it too.

    If you’ve no other way to tell which accounts are active it at least serves that purpose.

  • 3. Peter  |  January 6th, 2014 at 14:58 UTC

    s/Piper/Cohen/ – duh!

  • 4. Kaz Augustin  |  January 7th, 2014 at 06:21 UTC

    Great reference. Thanks.

  • 5. Peter  |  January 7th, 2014 at 09:53 UTC

    The usual links I dole out on this occasion:

    * Fred Cohen revisits his 1997 writing http://all.net/Analyst/2011-04.pdf
    * RJA – http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c02.pdf
    * Spaf – http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
    * Schneier – http://www.schneier.com/blog/archives/2010/11/changing_passwo.html

  • 6. Dan Cvrcek  |  January 7th, 2014 at 10:16 UTC

    I guess there are two things that make it hard to argue with users or IT managers when they say that password change must be enforced:

    1. security “pop culture” – security companies and experts keep saying that passwords must be changed (often). I don’t think they know why they say it but it sounds like they know what they talk about.

    2. audit requirements – they are being enforced and independent “experts” audit them. They would use checklists with all sorts of questions to collect data for assessing your IT security. I think checklists are excellent tools as they preserve knowledge of previous generations of auditors. Unfortunately they also hide potential ignorance of the current generation of auditors. At the end, these have to write a management overview and recommendations and it’s too easy to say “you have to change passwords so we can tick a box” instead of giving a thought to why.

  • 7. Dan Cvrcek  |  January 7th, 2014 at 10:36 UTC

    @Kaz Augustin

    There are some good references above. My short version would be…

    With any security system you ask
    1. what are the threats
    2. how do I find out about incidents
    3. what are impacts of incidents
    4. how can I mitigate impacts
    5. how can I mitigate threats
    6. how can I mitigate incidents
    7. what are effects of changes in response to 4.,5.,6

    The question is about password change (ad 4, 5, 6)

    The most common threats are:
    a) password is compromised after a server is compromised
    b) your password is key logged
    c) your password is weak and can be guessed

    ad 7. Changing passwords (assuming you can remember a good one) increases probability of a) and c) as the next password(s) will be weaker. Threat b) remains the same.

    ad 2. you will only find out about your password compromise after it has been exploited. Empirical fact.
    ad 1. the list of threats remains the same when you change your password.

    ad 3. will the impact be smaller when I limit the window of opportunity for attacker by 30 days?
    This is, in my opinion, the only IMPORTANT aspect of this issue.
    If you think you will find out about your password being misused and you can do it within 30 days, the gain of password change is rather questionable.
    If you think your password can be exploited in a way that you will not notice OR the impact of compromise will keep increasing with time you should consider whether password change would make a positive impact.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

January 2014
M T W T F S S
« Dec   Feb »
 12345
6789101112
13141516171819
20212223242526
2728293031