TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Secure password explanation? From:yehoshua paul <yehoshua -dot- p -at- technicalwriting -dot- com> To:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> Date:Mon, 18 Jun 2012 19:15:27 +0300
Because it's easier to create a universal rule banning double characters
than come up with a specific rule for each pattern that leads to a weak
password. For example "aabbccdd" or "111444."
Yehoshua Paul,
Community contributor and documentation expert,
www.technicalwriting.com
On Mon, Jun 18, 2012 at 7:04 PM, McLauchlan, Kevin <
Kevin -dot- McLauchlan -at- safenet-inc -dot- com> wrote:
> Certain database apps from a certain big company (no names, but it's
> initial is O), that I sometimes need to use, set a bunch of rather
> stringent conditions on new passwords, including a ban on double characters
> - so no words with double vowels or double consonants, and no repeated
> digits or punctuation. It's a real pain, given that the apps also force
> password changes every 60 days.
>
> This is actually more severe than the password best practice that I
> currently recommend in my customer docs (we're a cryptographic hardware and
> software company...).
>
> Naturally, I'd like to keep up with the times and with valid security
> procedures. But I just haven't been able to discover what security
> advantage is conferred by avoiding double letters, double numbers, or
> double punctuation. Does anybody know?
>
> When I suggest a practice or restriction, I like to be able to back it up
> with a quick explanation, so it doesn't look totally arbitrary.
> I've drawn a blank trying to imagine what advantage an attacker gains if a
> (say) 20-character password were to include a pair of identical characters.
> Yes, it's true that the subset of all words having two identical characters
> side-by-side is smaller than the set of all words, but there's no way to
> know that it's a word, and if it is, where it starts or ends within the
> string. It could as easily be the last character in one random word
> followed by the first character in another random word. It could be the
> letters that result from taking the first letter of each word in a phrase.
> It could be a pair of numbers in a larger number.
>
> For that matter, forcing a no-doubles rule actually shrinks the available
> string space and makes it non-random. Most crypto apps want greater entropy
> in seeds and inputs, not less.
>
> A casual query to a security architect garnered a head-scratch and a reply
> of "You've got me there...".
>
> Someone else - of a cynical mind - suggested that the O requirement was
> "probably just optics" ... trying to impress the uninformed with a bogus
> stringency that conveyed no actual advantage in security.
>
> Anybody?
>
> -k
>
>
>
>
> The information contained in this electronic mail transmission
> may be privileged and confidential, and therefore, protected
> from disclosure. If you have received this communication in
> error, please notify us immediately by replying to this
> message and deleting it from your computer without copying
> or disclosing it.
>
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Create and publish documentation through multiple channels with
> Doc-To-Help. Choose your authoring formats and get any output you may need.
>
> Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
>
>http://bit.ly/doc-to-help
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as
> yehoshua -dot- p -at- technicalwriting -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.