-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 That's why I suggested clientside use, and reasoned that it could all even be used plaintext instead of hashes, instead of the old password being kept compromised server side, have it drawn when the user enters it to change the password.
Someone else suggested keeping or even publishing password histories. From there we could have hashes of those, kept server side, created and transmitted along with the new password. Since we're forcing checks to ensure dissimilarity, we can be relatively sure that even if we used something quick to pre image, like md5, knowing what the password was like, but now wasn't, wouldn't give aid them, necessarily. Otherwise we'd just be defaulting back to an almost lm hash level of pointlessness. Landon - -- Violence is the last refuge of the incompetent. - -------- Original Message -------- From: "[email protected]" <[email protected]> Sent: Thu Jan 05 08:10:57 EST 2012 To: Landon <[email protected]> Cc: [email protected] Subject: Re: [cryptography] Password non-similarity? On Sat, Dec 31, 2011 at 5:02 PM, Landon <[email protected]> wrote: > > A lot of the password reuse is simply adding +1 or something on > the end. Since the base of the password stays the same, couldn't > you just hash the first and second halves of the new and old > passwords separately and compare each pair? (Or any arbitrary > length) Then if they match you can reject the password. > Sounds reasonable, but.... This utterly breaks security from offline attacks unless you double the length of the required password. Now, instead of brute-forcing 8 or 10ish character passwords, an attacker that obtained the hashes must only brute force two 4 or 5ish character sub-passwords - a much easier proposition. - ---- - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQJBBAEBCgArBQJPBfPYJBxMYW5kb24gSHVybGV5IDxsanJodXJsZXlAZ21haWwu Y29tPgAKCRA3qYf9H1SVrNPWD/sEDn5H1VJJIkvTuOtly4bhHQQcQxFmQR6e1J7P npOugaxAq5CJXB54NqTA7dNZDkL5flQiobQrMep3XIu8rLf5CZKlte2jOUIwrXl3 D0iICxxdvJLvpvaQvKyNkLRMwOYJQ1B/GFq8OuqTenmsGc/h9HaKuRPkv3rdwu4i uHzZ7g4wYwggLpBdg/D9soBv7BCfyEPjuGnIMLiCYd7+r6bbKCiM/25YHvRG/v7A TKhnhEu4MGTONPmrjpIzDotbRBCV9VO+NoeltJVLnaE1GMtr9e+pipqAmeeZxYjW B5+KaKkRtc2njj7mzSzU09N15ppafRQ68AN0nODyc7BoJds6ZHfA6RjrjrINdAWv Yy40/2Y6YWWpjSvmcjp0qcIkXYn8lnWOzflp7mfcn11ApigNBgWTiXqFG3YTxTY5 g46KPotJjVuk9K3iNFLzMv/VKFq3vHSbeT3xUtdI+ppRmZqFctdf+IylU+vmHmRv ySnzuiOLPJGzhB9VOI5S0Uw03mKadMqeOs36poWpt4m38Ro0m9wv94Ul6ZBQJ4Qi L9e8CijwcjzEpn+vVrS+Iu9Fwl2RwYk6cZM+wTRzAJnmbyw2QY8HogggSa76MI4f fLoAP+7seaKwEWX5wLoG2b/16o2HeOAabKcuf/y6quCIs7Lyk/8A7EI5PPAiMymC 0iJlTQ== =1tbM -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
