Branko Čibej wrote on Tue, Mar 27, 2012 at 05:29:59 +0200:
> On 27.03.2012 05:23, Greg Stein wrote:
> > On Mon, Mar 26, 2012 at 21:05, Branko Čibej <brane_at_apache.org> wrote:
> >> On 26.03.2012 17:45, Greg Hudson wrote:
> >>> On 03/26/2012 09:00 AM, C. Michael Pilato wrote:
> >>>> The on-disk cache will contain everything it does today where
> >>>> plaintext caching is enabled, save that the password won't be
> >>>> plaintext, and there will be a bit of known encrypted text (for
> >>>> passphrase validation).
> >>> Is it important to be able to locally validate the passphrase? That
> >>> property intrinsically enables offline dictionary attacks.
> >> I was going to say the same. When I read "known encrypted text" my hair
> >> stood on end. :)
> >> You don't need passphrase validation. If the passphase is wrong, then
> >> the recovered password will be wrong, too. It is bad practice to tell
> >> people that they used the wrong passphrase, and it's even better if you
> >> don't even know that it's wrong.
> > While discussing this on IRC some, I did think of one case where you
> > want to know they got the correct master passphrase: when they are
> > updating a server's password. A mis-entry could completely garble the
> > stored/encrypted contents.
Don't ew have some other ways of addresing that use-case? Such as, say,
encrypting a random string, and at decrypting compare the decrypted
text's sha1 to the value computed at encryption time?
(haven't had coffee yet)
> I dunno, all the systems I've used rely on the user correctly typing in
> the passphrase in this case (and usually that means
> verification-by-repetition). I'm really not comfortable with giving
> potential crackers such a leg up.
> I think it's even better to give the user the option to echo the
> passphrase in plain (on screen only, of course) rather than store any
> passphrase-derived bits (except for encrypted passwords) on disk.
> -- Brane
Received on 2012-03-27 06:56:04 CEST