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 <br...@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 >
