Date: Wed, 03 Sep 2014 06:43:53 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Second factor (was A review per day - Schvrch)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/03/2014 02:41 AM, Krisztián Pintér wrote:
> 
> Bill Cox (at Wednesday, September 3, 2014, 3:33:27 AM):
> 
>> Is this why you included a ROM in Gambit?
> 
> no, i wanted a second factor in the auth scheme, namely the "have",
> and i wanted it to be relatively hard to steal. not that i achieved
> this goal, because stealing a ~100MB file is not particularly
> difficult these days. not much more difficult than stealing a 32
> byte file.
> 

Second factor is something that I think a lot of entries with a secret
key or local parameter or data field.  I don't think it has to be
integrated in the memory hashing part unless we're trying to build a
Yescrypt or EARWORM style authentication server, though it is best if
the user isn't expected to hash the ROM himself.  TrueCrypt has a
minor weakness in that they use CRC32 hashes for key files rather than
a real hash, enabling files to be tweaked such that they don't impact
the hash result.

There is a second factor hack for TrueCrypt using a bootable USB
stick.  The cool part is you no longer need a master boot record or
volume header on the encrypted hard-disk, which is basically a little
header saying, "I am a TrueCrypt Drive and here are the salt and
password hash you need to brute-force attack me.  I'm bending over for
you."

The hard part about second factor is protecting it, IMO.  I have a
GnuPG smartcard now in my pocket, which may mean that my secret
signing key is harder to steal than before.  Without such a device,
how can users keep any random infected machine they plug it into from
hacking them?

Even with such a device, how can I know that malware isn't signing
random things left and right while I have it plugged in?  It could
locate my encrypted BitCoin wallet, and just sit there for years
waiting for me to plug in my USB key.

A dumb problem with existing second factor schemes where you have a
security token is that they seem to simply share a secret with the
server.  I see popular security companies like Forticlient have lame
processes going on at the protocol level, meaning if the client
doesn't see it, they feel no need to make it very secure.  For second
factor, they first tell you your token guess is wrong before asking
for the password, and they do nothing to protect a password once it's
typed in.  My point is we *can't* trust these closed-source companies
to protect the shared secret in a way that makes it hard for an
attacker to gain both the password and security token databases.

In other words, the security token you get from work may be quite lame
as defense against brute-force offline attacks.

Getting second factor right is hard!  Anyone have any really good
non-patented ideas?

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUBvDlAAoJEAcQZQdOpZUZCM0P/2ybddq+hNyc8qEtsWTgEnFJ
JxeBWW5b9+OCmELqLNWbzXcHwk/KsMM4B6T692KKMryyo7J829+1z6QteWws4+uR
yR4c8wWgoMitRs4NhjaV4W/UvcuVGJge3EPP9FUocQU3zABwKcd8xcw0sewLMPvl
UtXJSwtOKWh7mXz2zD7rcYo46nDlKx8DABmJSQnqT6PqeBPISFkRqQ9of0U96XCL
DA+IdufzenpucyDX1+qsS5+9wk50ShtxaPYVxD1+sJ6YWtvfOQi2RlFpzjrBly/r
Ju1ql3wdSCxWhA6UdWl8TjbsdCNiIu4ozX5o2YWgnnwQDWMt/MOAxb24VHQDuj09
iOJfj3NuLIewkvsU+L23bCz7fyHMs01F2fsk0tXvAvf5AqOXgDl2CSwgrLPEw720
x99AeKy5wxJ0d/kNG9VaSfihRGu9H+Sdsme78qNWApUNNcUxt3l5xXsiCXioJQpJ
38+00kOKrc1GDgRifPi91mait4r7B7iD4fdnneUlSNrkcGdzBSj8vd99PsFMpzyS
zdzodm7WVj/IyCli4+iBw/TjgdobtOaMFkpQQm9eD0hM9b9L7c/+Zd7XYOHpVlvJ
RHcCFFBjBML5KArp0WKjViLtWcH5YElr7lRhODYsAz5IuJqeTdSElFc3EFunvlFo
lcVY6jZ+NzRr1LdbexCH
=cKv0
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists