Usability of using Special Characters in System-Generated One-Time Passcodes

21 Aug 2005 - 12:31am
8 years ago
3 replies
566 reads
theomandel
2003

I am looking for usability concerns and guidelines regarding the use of
special characters in system-generated password codes. Any comments or
examples are appreciated.

Here's the situation: A system-generated code is sent to the user via e-mail
so he/she can type it or copy and paste it when going through the process of
obtaining a digital identity. A second system-generated code must be
delivered to the user by a supervisor, person-to-person, which may be by
phone call or also by e-mail. These are one-time use codes only.

Obviously, there are general guidelines regarding special characters in
passwords from the security aspect. However, from the usability perspective,
I am looking to address if there are issues with some special characters
when delivered by e-mail or voice and the user must then enter the password
or copy-and-paste it.

Currently, the password codes include A-Z, 1-9 and exclude 1, I, 0, O, Q, V,
and W. Potential special characters include: %, &, *, +, =,?, #, @, /, \, (,
and ). The goal is to increased randomness that will allow the password
codes to be shortened. The tradeoff is more complexity vs. a a shorter code.

For instance, I would not recommending using the forward slash (/) or
backward slash (\), since they are so similar and they are also difficult to
describe by voice.

Regards,
Theo Mandel, Ph.D.

Comments

21 Aug 2005 - 12:04pm
Peter Bagnall
2003

On 21 Aug 2005, at 06:31, Theo Mandel, Ph.D. wrote:
> Currently, the password codes include A-Z, 1-9 and exclude 1, I, 0, O,
> Q, V,
> and W. Potential special characters include: %, &, *, +, =,?, #, @, /,
> \, (,
> and ). The goal is to increased randomness that will allow the password
> codes to be shortened. The tradeoff is more complexity vs. a a shorter
> code.

My own feeling, having been given passwords over the phone many times
is that complexity is the real killer. I generally prefer longer rather
than more complex.

It's made worse by some cultural differences, for example in the UK we
call # 'hash' whereas I believe in the US it's called 'pound'.
Different keyboards may not have some symbols, or inexperienced users
may not know where they are. (typing # on a UK keyboard on a Mac is
awkward for example). Most of the symbols you've mentioned are
generally ok, except for #. I don't know if other symbols might cause
problems in other cultures. (Of course we're limited to those that use
a Roman alphabet here anyhow!).

An idea that may or may not be useful is, and is underused in
passwords, is chunking. Would your system allow you to have 3 or 4
character blocks, separated by a space, rather like the way credit card
numbers are written?

A password might look like....

ak4k wp9i qk2f g4m9 2fg7

Each block is easy to enter, and you can check it has been
received/entered correctly much more easily. Microsoft use a
5-character block form for their licence keys, and this makes the
length of them much easier to manage.

Once the password goes into the underlying system you may have to strip
spaces out, but that's simple.

Hope that's of some help.
--Pete

----------------------------------------------------------
Solitude, in the sense of being often alone, is essential to
any depth of meditation or of character; and solitude in the
presence of natural beauty and grandeur, is the cradle of
thought and aspirations which are not only good for the
individual, but which society could ill do without.
- John Stuart Mill, 1806 - 1873

Peter Bagnall - http://people.surfaceeffect.com/pete/

21 Aug 2005 - 4:36pm
Nick Ragouzis
2004

Theo,

You should re-think this protocol.

Your impulse for enlarging the key space was correct. I agree
with Peter, however: adding these special characters probably
increases the communications costs and error rate more
significantly than would a longer key.

As far as seeking that balance (larger key space vs user-user
communication burden/errors) you're much better off adding the
distinction between CAPS and lowercase. For a short 8-octet key
(keeping your exclusions) that change would give you a 19-OOM
(order of magnitude) increase rather the 11-OOM increase of your
"special character" scheme.

The first para above addresses your usability question, while
the second addresses your security objective.

I should say it *partly* address your security objective.

For one, given the other aspects you mention, considering the
necessary stance for an attacker, there's little difference in
adding those special chars -- they've already assumed them in
b/c once they've assumed a long-ish key and a reasonably rich
key space, it's much more expensive to run the crack twice
(i.e., under such assumptions they only exclude octets not
reasonably communicable in the assumed problem and language
domains).

More significantly and globally, however, there are two other
elements to consider (just for starters):
1) The lifetimes of the key(s) as valid for obtaining the
DigitalID.
2) The role of your key scheme with respect to the sort
of attacks made likely by the overall scheme.

It's this second item that most conditions your overall scheme.
And leads to an interesting conclusion.

If the two keys are generated by a system at the time of
parameterizing the DigitalID, which in today's technology they
naturally are, then presumably your protocol takes the care to
distribute the two keys via separate channels and separate times.
Including protections for delivery, storage, and viewing at the
two user's ends (the user and the "supervisor"). If it doesn't
then the rest of the protocol is a charade.

Bringing them back through the same channel (the user's channel)
means, in addition, that you've protected against common attacks
from the user's end. Again, if not then the extra fiddling of
partially splitting (in time domain) the secret isn't adding
anything except presenting the user the façade of protection,
through introduction of extra hassle.

Now, if we assume that you've accomplished both of those
protections, and attackers now don't have a long time to
attempt an attack, and probably only one, or perhaps at max
three, attempts, you need only have a small key separate from
the larger "user" key.

The interesting conclusion:
A simple word would do -- that is, a word chosen randomly
from the language of the user.

This should not be surprising, since it is related to what is
being used when a short check code is associated with a long key
-- of which we are all pretty familiar I should think.

And in addition to fully meeting the only serviceable objective
of the (secured as assumed above) protocol you've described
(more on this objective below), it is more usable.

- - -

But, to be complete, given that this proposal has got this far
... to ask an interaction designer ... I doubt the other
preventative conditions have been put in place. There might be
more to your protocol, but only design objective of the protocol
you've detailed could have been to credential the user ...
through the agency of the supervisor.

If you are aiming not only to use the supervisor as a
credentialing agent, but also as to enhance protection, you'd
*handle* these keys differently.

Further, your protocol depends fully on assumptions not
sanctioned in any security protocol: that the supervisor isn't
an attacker who would use the knowledge your scheme introduces
of the request, the timing limitations, and even access to the
same email (e.g.,) network, to some advantage. Or that a devious
'employee' could successfully collude with someone having access
to the manager's receipt of that split of the key.

Responding to either of these concerns removes any need for
communicating the keys in the way you describe and any concern
over the existence (in either key, if you'd still have two) of
special characters, and so on.

Before you delve into the interaction design aspects you might
ask your security officer to take a look at the whole protocol.
One place to start is to define the actual assets being protected
against what risks, and the vulnerabilities and threats being
considered.

--Nick

22 Aug 2005 - 11:12am
Ted Boren
2005

Totally agree with Pete regarding the phone issue. Even fairly well-known
symbols do not always have well known or standard names. Is it a "dash" or a
"hyphen" or a "minus"? Does everybody know what an "ampersand" is? I think you
also run the risk of having people misunderstand, and spell out the sound they
hear instead of using the symbol on their keyboard (@ = "A-T").

Also note that lengthening the password by just one letter or number greatly
increases the number of possible permutations... without having to audibly
decipher the symbols. By going with truly random passwords, you've already
greatly increased the difficulty of guessing the passwords.

Good luck,
Ted Boren

>>> "Peter Bagnall" <pete at surfaceeffect.com> 8/21/2005 11:04:10 AM >>>
On 21 Aug 2005, at 06:31, Theo Mandel, Ph.D. wrote:
> Currently, the password codes include A-Z, 1-9 and exclude 1, I, 0, O,
> Q, V,
> and W. Potential special characters include: %, &, *, +, =,?, #, @, /,
> \, (,
> and ). The goal is to increased randomness that will allow the password
> codes to be shortened. The tradeoff is more complexity vs. a a shorter
> code.

My own feeling, having been given passwords over the phone many times
is that complexity is the real killer. I generally prefer longer rather
than more complex.

It's made worse by some cultural differences, for example in the UK we
call # 'hash' whereas I believe in the US it's called 'pound'.
Different keyboards may not have some symbols, or inexperienced users
may not know where they are. (typing # on a UK keyboard on a Mac is
awkward for example). Most of the symbols you've mentioned are
generally ok, except for #. I don't know if other symbols might cause
problems in other cultures. (Of course we're limited to those that use
a Roman alphabet here anyhow!).

An idea that may or may not be useful is, and is underused in
passwords, is chunking. Would your system allow you to have 3 or 4
character blocks, separated by a space, rather like the way credit card
numbers are written?

A password might look like....

ak4k wp9i qk2f g4m9 2fg7

Each block is easy to enter, and you can check it has been
received/entered correctly much more easily. Microsoft use a
5-character block form for their licence keys, and this makes the
length of them much easier to manage.

Once the password goes into the underlying system you may have to strip
spaces out, but that's simple.

Hope that's of some help.
--Pete

----------------------------------------------------------
Solitude, in the sense of being often alone, is essential to
any depth of meditation or of character; and solitude in the
presence of natural beauty and grandeur, is the cradle of
thought and aspirations which are not only good for the
individual, but which society could ill do without.
- John Stuart Mill, 1806 - 1873

Peter Bagnall - http://people.surfaceeffect.com/pete/

------------------------------------------------------------------------------
This message may contain confidential information, and is
intended only for the use of the individual(s) to whom it
is addressed.
------------------------------------------------------------------------------

Syndicate content Get the feed