lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Sep 2014 06:43:53 -0400
From: Bill Cox <>
Subject: Re: [PHC] Second factor (was A review per day - Schvrch)

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

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?

Version: GnuPG v1


Powered by blists - more mailing lists