phc-discussions - Re: [PHC] PolyPassHash is broken

lists.openwall.net		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]

Message-ID: <541717D3.2090408@ciphershed.org>
Date: Mon, 15 Sep 2014 12:46:11 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PolyPassHash is broken

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

On 09/14/2014 06:05 PM, Justin Cappos wrote:
> I agree with your point, if _admins_ choose very weak passwords
> (<32 bits of entropy).  However, if admins are choosing passwords
> with very low entropy, then brute force over the network is also a
> big risk though.
> 
> Will any hashing scheme protect an admin account that chooses
> 'password' or 'abc123' as their password?  (At least PPH protects
> thresholdless accounts even with these horrid passwords.)
> 
> Making admins choose passwords that aren't completely broken seems
> to be a viable task.  Many organization already try to require this
> for all users by requiring some numbers / letters / min length,
> etc.
> 
> As always, the feedback / discussion is appreciated... Justin
> 

Just another thought... you could require during initial boot that
admins log in with additional authentication factors, which could be
something like Google Authenticator, or even just answering some
security questions (or even both).  Then, once the system has derived
the secret key, they could log in with just their password.  This
would be only slightly annoying to admins because the extra factors
would only be required occasionally, while providing a significant
security boost in case of a database leak.

Instead of leaking part of their password hash, you could just have an
additional hash, one for normal use using the secret key, and one with
a high level of security for logging in before the secret key is
available.

Would something like that work?

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

iQIcBAEBAgAGBQJUFxfPAAoJEAcQZQdOpZUZk/gQAKluTktOxRGcMUyY6AMtNPrJ
fNgqnm1uwH6crORWbCr0JHNvZ2uWQ7lzHH7WbjTPAxyuShvhfomMh09U3B0Yks86
jGMfGLiz/J+cQJk/d+iWIwe6nMXleR6eP3tCLXYIJYE2YB2IHvR26knhLdgYrLc4
jPZczjK0kzZjeWAkokhGOuoLfFrHlUZ70tprGg12YFVdDP6fAxqIoFmlxoI7nrD+
Xiayic2KxoLv/PMqH/TOceMegMk3Isnbs74+LPIKmR97WBpzMBBO4k73ThYRICIW
/oy6jlnvU8p0f5dCCM+TBeEt59GGdJdz/OGtvngZihJ8oLTetzfTwMB/2pcrzdb1
JGn91n9vVqEfq5mDrNMPO1/842Bg6lfuVVZaox+qJu3qNr/jZKL+R6LiHiMyUDgs
ISzYgh2sOr607nyqcsBaWGvbwBm0tDrxJylga/18se0/AMnImix8gk7SHabyKtfn
jUoIBQ3ks/zDu5ltXY4yuIryWc7CQbfV5xzxEPRqmfjySKLFP3QSpsZkB+iwqkML
BWBzUoYxnZiY9MJ8YvjNfGxCQm6UmOi5EmLSNEb2ytYW/fvHr1vvcWbER3oTqdwy
75LlR3dfSwb8NebvoorwSUEtqRSYuFf4frX+WN66eBZsEEnuR6BHG8XC/26AbV1S
fEUVv1AhlFL7E9qqFzB+
=Rx52
-----END PGP SIGNATURE-----