Innovative password security

The guys at <a
href="http://www.givemethekey.com">www.givemethekey.com</a> came up
with an interesting solution for password security. If you have to many
passwords to remember this might be just for you. From the FAQ:
"...GMTK is an attempt to solve this problem. (...) GMTK will generate
you a password based on your master-password. Instead of writting it
down or trying to memorize it, just come back everytime you need it and
GMTK you'll show it again for you."

This is the eternal password problem with password store and generation
utilities: They still have a master password as a gateway to the other
passwords.
If the master password is guessed or cracked, you're done.

There is always the question of a tradeoff..do you go with a SUPER LONG
and COMPLEX master password and if you do, what if you forget it, or
lose it?
Complex passwords can be hard to remember, so most people write it down
or store it somewhere. Someone can find it if they want to.

The eternal password security issue: easy to remember vs security: it
still hasn't been solved.

Now a biometric thumb scan to protect a slew of passwords..THAT's a
better solution. A biometric scan can generate a complex stream of
alphanumerics or whatever, and the user will not have to remember
anything..only to scan their thumb!
Cash in!

sorry to disagree but i prefer the master password. remembering ONE
password is not hard, even if it has to be a bit more complicated than
the usual.

biometric scans are very secure, thats for sure, but its no so
pratical.. and you need another device for that. what happens when you
go to a place where it is not available?

> If the master password is guessed or cracked, you're done.
I don't think so. If the Cracker has no Idea about the URL you used,
then it is no problem. I tried it out, and saw that you don't need to
use a URL. You can also use normal names like Yahoo. with this you have
an advanced security option.

But, the other problem is, if the service is not available. Then you
have no chance to get your password!

I would never use this for my Online-Banking-Account. But for an private
E-Mail Account this is a good thing IMO.



jms504 wrote:
> This is the eternal password problem with password store and generation
> utilities: They still have a master password as a gateway to the other
> passwords.
> If the master password is guessed or cracked, you're done.
>
> There is always the question of a tradeoff..do you go with a SUPER LONG
> and COMPLEX master password and if you do, what if you forget it, or
> lose it?
> Complex passwords can be hard to remember, so most people write it down
> or store it somewhere. Someone can find it if they want to.
>
> The eternal password security issue: easy to remember vs security: it
> still hasn't been solved.
>
> Now a biometric thumb scan to protect a slew of passwords..THAT's a
> better solution. A biometric scan can generate a complex stream of
> alphanumerics or whatever, and the user will not have to remember
> anything..only to scan their thumb!
> Cash in!
>

Agreed. And using a password to protect passwords that you forget is
like buying a tow truck to haul your truck around because it gets bad
gas mileage.

jms504 wrote:
> This is the eternal password problem with password store and generation
> utilities: They still have a master password as a gateway to the other
> passwords.
> If the master password is guessed or cracked, you're done.
>
> There is always the question of a tradeoff..do you go with a SUPER LONG
> and COMPLEX master password and if you do, what if you forget it, or
> lose it?
> Complex passwords can be hard to remember, so most people write it down
> or store it somewhere. Someone can find it if they want to.
>
> The eternal password security issue: easy to remember vs security: it
> still hasn't been solved.
>
> Now a biometric thumb scan to protect a slew of passwords..THAT's a
> better solution. A biometric scan can generate a complex stream of
> alphanumerics or whatever, and the user will not have to remember
> anything..only to scan their thumb!
> Cash in!
>

I'm just saying..your average user doesnt know how to do anything
beyond turn the computer on, go online and check email.
I'm looking at this from a sys admin standpoint. Users have ENOUGH
problems with simpler passwords.

As far as biometrics goes, bio devices are spawning that are low cost
and theyre spreading like wildfire. Basically sys admins are moving in
this direction. Just as you have to have a user name/pw to login to a
domain, you will also have to scan in. Two factor authentication is a
strong topic now in security. Bank cards are the next to jump on the 2
factor/biometric chain.

RIght now theyre investigating an extended(in length) card in which you
put your thumb on a sensor which is physically on the card to
authenticate.

nunodonato@gmail.com writes:
> sorry to disagree but i prefer the master password. remembering ONE
> password is not hard, even if it has to be a bit more complicated than
> the usual.
>
> biometric scans are very secure, thats for sure, but its no so
> pratical.. and you need another device for that. what happens when you
> go to a place where it is not available?

the issues are what are the treats and the countermeasures.

biometric information can be left around all over the place ... and
once compromised it can be a lot more difficult to re-issue a thumb
than it is to replace a compromised password (although there
have been a couple recent news items attempting to address
compromised biometrics).

frequently access passwords tend to be shared-secrets .... they tend
to be exposed in a lot more different places ... it is one of the
reasons for security recommendations that there has to be a unique
shared-secret for every unique security environment. This in turn
leads to people having several scores of different (shared-secret)
passwords that result in the difficult (human) memory problem 2and in
turn results the (shared-secret) password management problems.
http://www.garlic.com/~lynn/subpubkey.html#secret

The master password scenario tends to be simply a secret ... as
opposed to a shared-secret ... which tends to imply that there are a
much fewer places where they are exposed and may be subject to
compromise.

The basic model tends to be that there is some sort of container for
the authentication material ... either a software/file container
.... or a separate hardware token container.

The (master) password tends to be a countermeasure for a lost/stolen
"container" (whether it is a real physical container or purely
software container).

At a 100k foot level ... it is two-factor authentication:

* container (hardware or software), "something you have"
* (secret only, not shared-secret) password, "something you know"

.... lots of 3-factor related authentication posts
http://www.garlic.com/~lynn/subpubkey.html#3factor

multi-factor authenticatin carries with it the implication that the
different authentication factors are subject to different kinds of
vulnerability and threats (for instance "something you are" biometric
value and a "something you know" password value transmitted in the
same communication may be subject to a common evesdropping
vulnerability and replay attack ... negating the benefit of
having multi-factor authentication).

the overall integrity can be related to how easy it is to steal the
container, whether the owner realizes the container has been stolen
(physical or software copy), and how hard it is to crack the (master)
pin/password.

a separate hardware container may be harder to steal than a software
file resident on an extremely vulnerable internet connected
PC. Vulnerable, internet connected PC may also be subject to
keyloggers (capturing the master password) and sniffing (capturing the
actual shared-secret passwords as they are being used).

So compare various threat models to hardware token with private key
and infrastructures that replace shared-secret password registration
with registration of public keys ... and digital signature
verification in lieu of password checking.

Requiring unique shared-secret registration for every unique security
domain is because the shared-secret is used for both authentication as
well as origination (i.e. knowing the shared-secret can be sufficient
for impersonation). A public key can only be used for authentication,
but not for impersonation ... so the same public key can be registered
in a large number of different places w/o increasing the threat of
impersonation (that can happen if the same shared secret is repeatedly
used).

Correctly implemented digital signature protocols result in a unique
value for every authentication, eliminating threat of evesdropping and
replay attacks for impersonation.

A real hardware token tends to eliminate electronic, software theft
(which can happen with emulated software containers).

So a hardware token tends to require physical stealing the object.

For this situation, pin/password (required for token operation) is a
countermeasure for physical lost/stolen token ... as long as the
pin/password hasn't been written on the token.

A hardware token with a built in fingerprint sensor ... might leave
around a latent print on the sensor ... so if the token is stolen
... the thief may be able to lift the latent print and spoof the
sensor. Some organizations are featuring "line sensor" (where you have
to drag you finger across the sensor) as a security enhancement
(compared to full finger sensors where a latent print may be left
around).


--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

"Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message
news:m3r7c8v4nm.fsf@lhwlinux.garlic.com...
> nunodonato@gmail.com writes:
> > sorry to disagree but i prefer the master password. remembering ONE
> > password is not hard, even if it has to be a bit more complicated than
> > the usual.
> >
> > biometric scans are very secure, thats for sure, but its no so
> > pratical.. and you need another device for that. what happens when you
> > go to a place where it is not available?
>
> the issues are what are the treats and the countermeasures.

<harsh snip>

Nice post.

The big argument between SSO (as the subject has called for at least seven
years) and non-SSO has always been that loss of a single credential exposes
everything, vs. username couplets stuck on Post-Its all over the place (been
there, etc.)

Shame that we no longer have the option for *two* independent passwords
(possibly one of HP/Compaq/DEC's patents). That was a useful compromise (as
well as allowing the requirement for *two* people to authorise a privileged
login)

But. The only way it ever works with any degree of safety is to not have the
store on the (vulnerable) local machine.

And that brings the issue of a juicy target that you - as the user - has to
trust absolutely. Excellent for corporations, not so hot for individuals,
IMHO.

--

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!

(Caveat: the company that indirectly pays for my food & beer has an SSO
offering. I'm not trying to sell anything here. But I have some degree of
practical experience; should have even more on Monday, after integrating it
with external software for a demo... ;o)

"Hairy One Kenobi" <abuse@[127.0.0.1]> writes:
> Nice post.
>
> The big argument between SSO (as the subject has called for at least
> seven years) and non-SSO has always been that loss of a single
> credential exposes everything, vs. username couplets stuck on
> Post-Its all over the place (been there, etc.)
>
> Shame that we no longer have the option for *two* independent
> passwords (possibly one of HP/Compaq/DEC's patents). That was a
> useful compromise (as well as allowing the requirement for *two*
> people to authorise a privileged login)
>
> But. The only way it ever works with any degree of safety is to not
> have the store on the (vulnerable) local machine.
>
> And that brings the issue of a juicy target that you - as the user -
> has to trust absolutely. Excellent for corporations, not so hot for
> individuals, IMHO.

a person centric token ... say with digital signature verification as
the mechanism for implying "something you have" authentication
(i.e. hardware token that calculates key pair and never exposes the
private key) ... then the person can determine how many tokens and/or
how many environments used with each token.

an institution might be concerned about the integrity of the token
.... but using a single token with multiple institutions doesn't impact
any specific institution. using a single token for multiple
institutions or unique token per institution ... is a person centric
consideration (modulo the integrity level of the token).

however if a person tends to carry all tokens on the same ring ...
then whether they are carrying a single token or multiple tokens on
that ring has little impact on the lost/stolen threat scenario
.... they will all tend to be lost/stolen at the same time.

the objective of multiple tokens is if they have independent threats
.... if they are subject to a common threat then the advantage of
multiple tokens is lost.

there is a similar argument about multiple credit cards as
countermeasure for lost/stolen threat ... which is negated if they are
all carried in the same wallet ... since the lost/stolen scenario
tends to be the whole wallet ... not individual contents.

so if you really want to get fancy ... some topic drift to
security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

one of the other countermeasures to lost/stolen in an online
environment is the person recognizing that there has been a
lost/stolen compromize and reporting it (limiting the scope/duration
of the compromise). many of the PC/software and pure password based
infrastructures can suffer a lost/stolen compromise w/o the person
recognizing it has happened.

in any case, in a person-centric scenario ... a person wishing to
having multiple tokens ... should recognize that they would be using
multiple tokens instead of single token as a countermeasure to
lost/stolen ... which means that the person needs to be prepared
to keep the different tokens physically separate.

some past posts on person-centric models
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb?>?
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

"Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message
news:m3y86fueea.fsf@lhwlinux.garlic.com...
> "Hairy One Kenobi" <abuse@[127.0.0.1]> writes:

<snip>

> > But. The only way it ever works with any degree of safety is to not
> > have the store on the (vulnerable) local machine.
> >
> > And that brings the issue of a juicy target that you - as the user -
> > has to trust absolutely. Excellent for corporations, not so hot for
> > individuals, IMHO.
>
> a person centric token ... say with digital signature verification as
> the mechanism for implying "something you have" authentication
> (i.e. hardware token that calculates key pair and never exposes the
> private key) ... then the person can determine how many tokens and/or
> how many environments used with each token.

<snip>

> many of the PC/software and pure password based
> infrastructures can suffer a lost/stolen compromise w/o the person
> recognizing it has happened.

On the other hand, any hardware that has been manufactured in the first
place - unless incorporating something genuinely random as part of the
physical manufacturing process - can be copied without the user knowing
about it. Or stolen without them necessarily realising it immediately.

Sure, an algorithmic approach raises the bar from a username couplet
transmitted in clear, but it's simply a matter of degrees.

The distributed hardware approach also has one fundamental flaw, IMV - what
happens when the /class/ of devices is compromised? 100% failure and the
requirement to.. what? Potentially suspend access to critical systems?

It's bad enough when, say, a couple of hundred thousand Amex cards have been
compromised. What happens to tens of million national ID cards or passports?
Can't remember the name of the website that "misplaced" everyone's details
(bar that it was in the US), but I'll bet that the first most people knew
about it was when a shiny new card appeared in the post.

Just one reason why the Austrian Government (to take an example) has an
algorithmic requirement (to ensure that queries can only be performed in a
single direction), but are platform agnostic.

Their favoured platforms appear to be existing Smartcards issued by banks,
and mobile phones. This device provides the username-equivalent, the user
provides their shared-secret [PIN].

It does, of course, mean that the government is continually playing catch-up
on technology, but who cares? It's not as though they're paying to maintain
the devices.. they "only" have to maintain and protect a central silo of
credentials. In the event of a compromise, they "only" have to generate new
credentials and reset their policies on what they consider to be acceptable
platforms.

The other, hidden, silo (which contains the actual system credentials) is
untouched, except in the event of a central breach.

Handing that choice to the individual user (which I think you are
advocating?) is not quite the same thing - if, say, I'd bought a few
JavaKeys back in 1997, should an institution /really/ consider this as
secure as the much, much stronger key lengths in common use today? Would
your average bank be quite so cavalier with their reputation?

OK, so this has veered a fair way from SSO, but that's what makes Usenet so
interesting :o)

H1K