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]
Date: Tue, 25 Mar 2014 16:35:28 -0400
From: Justin Cappos <jcappos@....edu>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] New password hashing entry: PolyPassHash

>
>
> I'm not saying it happens in every single attack, or even in most, what
> I'm saying is in the event of memory being compromised you have two
> potential scenarios.
>
> What I'm really querying is whether your algorithm provides any
> significant advantages over using a simple secret key in memory.
>
>
Key management / usability for admins, which I think is important.   I know
our school does not do what you propose for most (possibly all) of the
servers they administer.


And similarly with most schemes that use a secret master key: the attacker
> still must brute-force the password hashes.  The only difference is they
> cannot even attempt to without the secret master key.
>

Well, they could attempt to crack the key.   However, that's not a good
argument for me to make because the search space is so large.   Similarly,
assuming reasonable keys are used, the search space for PolyPassHash is
also infeasibly large...


> Yeah, no worries - I like your idea, I'm just not sure how widely
> applicable it is.
>

Maybe you can help me understand more about where you would think it
doesn't apply.   To me, if you have a password hash database, you would
essentially always want to use it.

Make no mistake, I don't think what I propose is a panacea, but it seems to
me to be pretty much be strictly better than not using it...

Thanks,
Justin

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ