Including and storing the order of character entry in a password as an enhanced security measure

Question

I'm sure I will be quickly corrected if this is a stupid idea, or if it has already been tried. My question is: has this idea been tried before? If not, are there good reasons it would not work, or would not improve security?

It is easier for me to remember my current password algorithm by entering it in four different pieces. In order to enter those pieces correctly, I have to move the cursor around, so for example, first I might enter (this isn't it, just similar):

ihate

Then I might do:

Dirtyihate

and:

DirtyihateCommies

then finally:

Dirtyi9?7hateCommies

It just occurred to me: why couldn't you, as a part of the password confirmation, use not just the text of the password itself, but also the ORDER it was entered..?

I don't see any reason this would not be technically possible. It's true that getting people to take advantage of it would require a change in user mentality, and there might be a very large learning curve. However, at the same time, I assume that 99% of people who enter their password do it the same exact way every time, and so for those- the vast majority- they would not be effected by the change unless they wanted to be.

I also assume most folks directly enter their PW in sequential order every time (unless they make a mistake and go back to correct it), so they'd be unlikely to notice it. Only people who want to take advantage of the additional security would be impacted.

Including the order of when each character was entered would add a large amount of additional randomness to the password (and the magnitude of randomness would increase with every additional character added - e.g., for an 8 character password, if my math is right it would add 8! more possible iterations, 10! for a 10 character pw, etc etc).

An additional benefit, and I think this is probably the biggest potential for this idea, would be that you could store the password (encrypted) string itself separately from the (also encrypted) order on a server. In this way, if an attacker wanted to steal passwords and use them, the attacker would have to have BOTH sets of data in order to make use of them! A 20 character password - obtained from, say, a carelessly stored piece of paper - would still have >10^18 possible iterations.

So you (ie, someone smarter than me) could figure out a way to store - completely separately - these two interleaved forms of identity confirmation so that each is equally difficult to steal, but they are both checked at the time the pw is entered.

It would be really easy to store the password order, too. Just do it as a list integers. So for my example password above, the 20 character order might be stored like this:

6 7 8 9 10 1 18 19 20 2 3 4 5 11 12 13 14 15 16 17

Perhaps the idea could also be extended to things like private keys, though I don't know enough about the subject to say so definitively.

EDIT:

Perhaps the requirement of moving the cursor around is too arduous. What about rich-text passwords? Why not allow italics, bold, underline, etc etc, as part of password entry? How about color? As with the previous idea, nobody would HAVE to be affected. Only those who choose to be affected would be impacted, and similar to the previous idea, you could store the style information separately on a server for the enhanced protection from theft of a password database.

Answer 1

There are several reasons why this would be a sub-optimal security scheme. Here are a few:

1. The biggest issue with secure passwords is our memory, or our limited capacity for remembering passwords. We're pushing our memory limits as it is, and always working to devise new tricks to help better remember more secure passwords. This scheme introduces new components that must be memorized, without any advancement in memorization technique. That means that if we already at our memory limits, but now must remember entry order as well, something else needs to give, and given that entry order is not in and of itself particularly memorable, the sacrifices that we must make in the other aspects of the password are likely inordinately large.

2. Reduces or eliminates the ability to mask passwords. For a non-trivial scheme (I.E., not just appending and prepending password segments) it would be nearly impossible to mask passwords during entry as we do today. If we're going to be inserting character strings into the middle of the password somewhere, to do that with any reasonable speed and assurance of accuracy, we would need to be able to see what was already entered. This means that you can't mask the password with a string of asterisks or discs, which allows for shoulder-surfing and photographic plain-text password capture.

3. Would require a new generation of password managers. Currently, password managers have the ability to auto-enter passwords. If order is important, you have to have the ability for them to auto-type in a specific order, or continue to live with sequentially ordered passwords if you use a password manager. In the second case, which is the preferred mechanism today, and would likely continue to be preferred, you gain nothing from the entry-order scheme except for additional complexity.

4. This all has to be captured client-side. In your specified scenario, (a web application) by the time the request is sent to the server, the password is simply a field value, and HTML forms don't support any way to associate the manner in which the value was entered with the request. So, you need a way to both capture the entry order, and then submit it along with the request. And it needs to work with every input mechanism, for every client user agent.

5. As a user, the added entry complexity can be a significant barrier. Touch devices are one example of where this is going to be an issue. It's hard enough as it is to do data entry on a phone, and that's becoming the most prevalent form factor for consuming the web. Add having to move back and forth in the field as you enter a password, and it'll make you want to stab your eyeballs out with a stick. And if you think this is hard, it would be essentially impossible for some clients, such as voice-to-text tools that assist disabled users by allowing them to speak the values they want to enter.

I'm sure there are others, these are just a few obstacles I thought of off the top of my head. This scheme does add an element of complexity to passwords that doesn't exist today...That is true. It is not however, an ideal scheme for improving passwords. We're much better off promoting password managers and long, unique, random passwords that trying to find new gimmicks.

Answer 2

Clarifications:

If I understand you correctly you are interested in including the order a password is typed within the data needed to use it correctly.

For example if my password is typed out in order like this: 'p' 'a' 's' 's' 'w' 'o' 'r' 'd'

It would not work if someone typed 'w' 'o' 'r' 'd' and then clicked to the beginning and typed 'p' 'a' 's' 's'.

And the same would be true for the other way round. Assuming this is a correct interpretation, lets dive in to this fun idea! From here on out I'll call it 'password entry ordering' or PEO.

Addressing Password Entropy:

Firstly, lets lay aside the substantial difficulties with the design and implementation of a PEO system. What benefits would be obtained by this new system?

If I have a password of length n then theoretically there are n-1 possibilities of reordering the password by clicking to the end or beginning or middle and adding more text. This is assuming that a backspace or delete renders this process incomplete and requires a restart of this process. Well how much added entropy is that? How much harder is this POE password system to crack?

Well, if we treat PEO as some unique character that means going back or forward a set number of spaces (e.g a character that means '+3' - move three forward or '-3' - move three back) it turns out PEO does not increase password entropy more than adding a single random character unless the length of the password was longer than the set of all allowed characters within n. This is because there are only n-1 reordering possibilities within an n length password whereas there are 26+26+10 (every lowercase and uppercase letter and number - not mentioning the possibility that special characters) possible entries for a single character. So unless you are using a 62 character password, using an extra character will actually provide significantly better entropy than using a 'reorder'.

There are also some difficulties for implementing a system like this:

Hashing Algorithms - Storing passwords securely is usually done through a non-reversible process called hashing. At the moment, hashing algorithms take any length of input to calculate standard length hash values:

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

How would a hashing algorithm deal with the reordering you suggest? One possibility would be the way you suggest, to calculate a string of numbers and hash that string. However, as we talked about before, that string of numbers only really adds n-1 amounts of potential entropy because of its possibility to vary from 123456789101112 is limited by the length of the password.

Another way might be to take a reordering like I said and set it as a specific character or chunk of characters appended to the end or included within the password. Going back 4 characters to start typing again translates to '-4' going forward 3 translates to '+3'. But then, why would we not just want to use a few extra characters to provide additional security? This idea in itself is also deeply flawed because a good password guessing algorithm would just run through passwords with +1 +2 +3 -1 -2 -3 appended in sequence to the end and quickly eliminate the small added entropy for this sort of system. Further, since this is likely to be used in combination with words it provides an even easier formula to guess when these values would be included within a password.

Two Databases You mention that you want to store the value of a password and the value of its reordering in two different databases. If these password databases are equally easy to steal or crack then it wouldn't matter if you separated them, stealing one means you can steal the other. Why not store them securely as one database? This doesn't add much security as an application would need to reverse the encryption if you stored these two differently and needed them unencrypted to compute them properly. This in itself is a massive security flaw and is actually against many security standards.

Browser/Application Usage In order to use this sort of technique you would have to use a far more intrusive method of password capture that recorded actions as they were happening within your system. Browsers and applications are not built to track both position and order entered. HTML and other web forms are built to take an input not measure and watch the way that input is created. This would also be hugely problematic for smaller devices and clumsy fingers like mine. What if I make a mistake on my 12 character password and click it on accident, which on mobile is easy to do, do I have to start over?

Underlines, fonts etc. What you are really requesting here is a larger set of potential characters to be included within password entry. Ultimately the benefits of this would simply be to add a larger base set of possible components to a password. I think you'll find that there are plenty - Try these: ")*#!@:";'] Or if you want to get super cool and these work in some application these ones: c⌐◘â« that's just from messing around with alt and the num pad. One thing that definitely would help would be allowing specials, spaces, punctuation, etc. into password generation systems. That could increase the entropy and difficulty of password systems that only use numbers/letters/some specials. However, I think you'll find the set of currently available characters ordered in unique and somewhat lengthy ways provide enough entropy to avoid necessitating the inclusion of a larger base set of characters. Additionally, the user experience and security challenges are too large to make the POE system viable.

Practicality The most practical idea for improving password security is encouraging the use of encrypted, random-generating password managers like KeePass or others that can generate 40 character random strings uniquely. As for strong passwords that are required to be memorable there are plenty of ways to easily remember and use strong passphrases. If you need an example of one way to do this check out a post I wrote about it here. That was certainly a fun thought experiment but remember that there are often good reasons for standardized cryptography and sometimes adding fun ideas can detract from the proven security.