[kwlug-disc] Password change policy

[Erik Schnetter]

If you have the new password, if you assume ASCII characters (95 different
characters) and a 10-character password, then trying all possible
one-character changes only requires 940 tries. These would be tries using
the modified new password against the safely-stored (hashed, salted) old
password.

That's why one-character changes are unsafe if the old password has
leaked...

-erik


On Mon, Jun 18, 2018 at 7:30 PM, Raymond Chen <raymondchen625 at gmail.com>
wrote:

> Not sure how Doug's IT system detect single character change. Maybe it
> stores the old passwords in clear text for future comparison. And never the
> current password. Maybe asking for the current password when changing it
> serves this purpose too.
>
> On Mon, Jun 18, 2018, 16:33 Chamunks, <chamunks at gmail.com> wrote:
>
>> I don't know the episode of security now I heard it on, or the paper that
>> it was from but the specification that was responsible for this
>> irresponsible security practice has been finally updated and removed.
>>
>> Honestly I would look into implimenting something like SQRL once he's got
>> the forums online for support.  Apparently its finished.  It's passwordless
>> authentication.
>>
>> On Mon, Jun 18, 2018 at 3:38 PM doug moen <doug at moens.org> wrote:
>>
>>> These kinds of password change policies are bullshit. They impose an
>>> impossible burden on employees. You can't expect the majority of employees
>>> to construct and memorize a brand new, unique and highly secure password
>>> every three months (or whatever). Most people's brains don't work that way.
>>> Since it's an impossible burden, it forces employees to play cat and mouse
>>> with IT, and find some way to manage the passwords without IT discovering
>>> the method and finding a way to ban it. I created an algorithm for
>>> generating an infinite sequence of passwords, and moved to the next
>>> password in the sequence every three months. My sequence changed more than
>>> one character for each password in the sequence, and IT did not manage to
>>> detect and ban my algorithm. They were able to detect single character
>>> changes.
>>>
>>> I would suggest implementing two factor authentication, and giving
>>> everybody a yubikey.
>>>
>>> On 18 June 2018 at 14:52, Raymond Chen <raymondchen625 at gmail.com> wrote:
>>>
>>>> Most organizations ask their users to change their passwords
>>>> periodically, and also have some kind of mandatory password complexity
>>>> requirement. One day when I talked about this with some colleagues, I found
>>>> out quite a few of them used a strong password, but changed only one
>>>> character, probably increase a number there, when asked to change it. Like
>>>> from Ik0FmU>Hf to Ik1FmU>Hf to Ik2FmU>Hf
>>>> I think this is compromising the security, like writing it down on a
>>>> post-it on your monitor. But I can't think of a way to prevent this
>>>> technically. We shouldn't store the clear-text password of course. And we
>>>> should not find any clue on the similarity by just looking at the encrypted
>>>> text if it's a good encryption algorithm. How do we know the user only
>>>> changed one character?
>>>> Maybe we can pre-calculate all the variations when user specifies a
>>>> password and store the all the encrypted strings? But that's a waste of
>>>> resources, right?
>>>> And that might in fact push some users to using the post-it...
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Raymond
>>>>
>>>> _______________________________________________
>>>> kwlug-disc mailing list
>>>> kwlug-disc at kwlug.org
>>>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>>>
>>>>
>>> _______________________________________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org
>>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>


-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180618/5f72c935/attachment.htm>