Re: password length and required reset

[Justin Store <jrstore () MTU EDU>]

Hello Everyone,

We just kicked-off a project to increase our current length of 8 up to 14.
We chose 14 (with complexity) because it addresses the threat of offline
cracking with rainbow tables and brute forcing while also meeting the
recommendations in the CIS benchmarks for our primary OSs (Win10 and Server
2012) with further guidance taking from CIS Critical Security Control 5.7
which looks for passwords longer than 14 characters for systems that don't
support MFA. With these in mind, we settled on 14 as being the sweet spot
for addressing offline cracking and adhering to best practices as
recommended by CIS (makes auditors happy too).

However, we are curious as to what other institutions have already taken
this path. If you are enforcing passwords of 14 characters or longer,
please reach out to me if you don't mind. I won't take up much of your
time, but we're looking to further justify our decision by pointing to
other universities that have already tackled this change. Also, I would be
interested in hearing from anyone who has gone to 12 characters or longer
as a comparison.

In short, I would greatly appreciate anyone sending me an email simply
stating their minimum password length if it is 12 characters especially if
it is14 characters or longer.

Thanks in advance,
Justin

Justin Store
Security Architect
Michigan Tech University <http://www.mtu.edu/>
Information Technology <http://www.it.mtu.edu/>
906.487.1477

On Mon, Oct 10, 2016 at 7:29 PM, Steven Alexander <steven.alexander () kccd edu
> wrote:

> Mike,
>
>
>
> You are correct that the bar for preventing online guessing attacks is
> generally not a high one.
>
>
>
> Offline attacks are still important.  SQL injection often allows access to
> the password store without having administrative rights or server-level
> access.  Even in the case of a network breach where the attacker has
> achieved administrative rights, being able to easily crack passwords can
> enable the attacker to preserve access, cover his tracks, gain access to
> specialized applications (e.g. Banner, Datatel) pivot to additional
> systems, and/or access corresponding accounts at other sites/services.
> Additionally, having weak password requirements can make it easier for an
> attacker to get back in once you discover them and try to shut them out.
> If the attacker can easily crack the hashes in the old password store,
> he/she can make some smart guesses about the new passwords; for that
> purpose, even an online attack would be likely to succeed.
>
>
>
> Regards,
>
>
>
> Steven Alexander
>
> Director of IT Security
>
> Kern Community College District
>
> (661) 336-5111
>
>
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [mailto:
> SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Mike Cunningham
> *Sent:* Monday, October 10, 2016 1:46 PM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] password length and required reset
>
>
>
> You are of course assuming for these calculations that the entire password
> datastore has already been stolen and the hacker has a local copy of it to
> try and crack. And if someone has already got themselves that deep into
> your system your already in a boat load of trouble.  Even if someone used a
> tool to feed passwords to a logon page for a student information system at
> a very fast rate the invalid logon attempts account locking is going to
> slow things down a lot where even a 6 or 8 digit password with mixed case
> and numbers would take a few hundred years to crack on average.
>
>
>
> Mike Cunningham
>
>
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [
> mailto:SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>] *On
> Behalf Of *Steven Alexander
> *Sent:* Monday, October 10, 2016 2:04 PM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] password length and required reset
>
>
>
> Mike,
>
>
>
> The cracking speeds on that site are way too low and are probably based on
> cracking with a CPU which is not how hackers crack passwords.  The most
> popular tool for password cracking is hashcat which is capable of using
> graphics (GPU) cards to guess much faster.  The Open Security Research site
> lists the cracking speed for MD4 as 47.7 million passwords per second.  The
> screenshot currently on the hashcat website (http://hashcat.net/hashcat/)
> shows a benchmark of about 1 billion guesses per second for SHA-512 on a
> GeForce GTX 1080 card; MD4 is at least twenty times faster than that.
>
>
>
> A few years ago, Jeremi Gosney (who builds high-end rigs for security
> companies and law enforcement), built a five-machine cluster that could
> guess at a rate of about 350 billion per second (http://arstechnica.com/
> security/2012/12/25-gpu-cluster-cracks-every-standard-
> windows-password-in-6-hours/).  His company currently builds rigs that
> can get the same output from a single machine (https://gist.github.com/
> epixoip/a83d38f412b4737e99bbef804a270c40).  I don’t assume a hacker will
> put that much hardware to the task, but it serves as a useful high water
> mark and, with better GPUs, it might be practical in five years or so with
> a good gaming rig.  If you look at the breakdown, Jeremi’s benchmarks show
> over 40 billion guesses per second per GPU for MD4.
>
>
>
> My estimates, which I need to write up in more detail, are based on a few
> assumptions:
>
>
>
> 1)      Our theoretical hacker will have access to a good quality gaming
> machine with 1-2 reasonably current GPUs.  I estimate that he/she can guess
> 100 billion guesses per second which is on the high side (the max with two
> Nvidia 1080 cards is about 90 billion) but I expect passwords to be in use
> for a year or more.
>
> 2)      Our hacker will be happy to crack any account with access to
> sensitive data or admin privileges.  I assume 200 such accounts.  Because
> the passwords are unsalted, there is no penalty to guessing multiple
> passwords simultaneously.  Accordingly, my notion of a safe password
> requirement is based on the number of passwords that can be cracked per day
> rather than the amount of time it takes to try all passwords.
>
> 3)      Some of the passwords will fit the patterns or “topologies”
> identified by KoreLogic (https://blog.korelogic.com/
> blog/2014/04/04/pathwell_topologies ) , e.g. lllllllldddd (8l4d) where
> “l” is a lower case letter” and “d” is a number.  For estimation purposes,
> I suppose that all of the passwords fit a particular pattern; this will not
> be the case in practice, but it gives us a good margin of error.  In
> practice, an attacker will try many of the shorter patterns but only a few
> longer ones.
>
> 4)      The calculations below don’t make use of this, but I also assume
> that many users will use patterns that can be cracked using the “rules”
> that come with hashcat or Jon the Ripper.  These rules account for
> appending digits to a password, substituting $ for “s”, etc.  As passwords
> get longer, I think the KoreLogic topologies are more useful but
> rules-based cracking will still easily catch things like
> “PasswordPassword!”.
>
>
>
> In practice, penetration testers regularly crack 12+ character passwords
> and fifteen characters is not unheard of.  I assume that a black hat can do
> the same.
>
>
>
> Given these assumptions:
>
> 1)      A hacker should be able to crack eight character, lower case,
> alphanumeric passwords in as little as half a minute.
>
> 2)      A hacker should be able to crack all passwords matching the
> thirteen character pattern 9l4d, nine lower case followed by four digits,
> in about six days.
>
> 3)      A hacker should be able to crack one password per day, from a
> pool of 200, that matches the pattern 10l4d.
>
> 4)      If the 4d represents a birth year, a hacker can guess 4-5
> passwords per day matching the pattern 11l4d in a pool of 200.
>
> 5)      If the 4d represents a birth year and the letters are chosen from
> the twenty most common, a hacker can guess 4 passwords per day matching the
> pattern 12l4d in a pool of 200.
>
>
>
> Here is a snapshot from one of the spreadsheets I put together:
>
>
>
> [image: cid:image001.png@01D222E3.FF647560]
>
>
>
> My calculations are meant to ascertain best practices for password
> policies.  As an individual, it’s okay to pick shorter passwords if they
> are more complex.  For example, if you generate a random 12 character
> alphanumeric password, it will be much stronger than a 16 character
> password in the format 12l4d.
>
>
>
> As a matter of policy, I’m not very fond of requiring three or four out of
> four character sets.  People are exceedingly likely to capitalize the first
> letter, put digits at the beginning or end, and use one of a few characters
> ($ or !) at the very end of the password.  It doesn’t add nearly as much
> complexity as we intend; if people picked (or we assigned) passwords like
> “x_j7XrB9%s”, we could safely use much shorter passwords.
>
>
>
> Regards,
>
>
>
> Steven Alexander
>
> Director of IT Security
>
> Kern Community College District
>
> (661) 336-5111
>
>
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [
> mailto:SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>] *On
> Behalf Of *Mike Cunningham
> *Sent:* Monday, October 10, 2016 9:54 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] password length and required reset
>
>
>
> Steve, where do you get the stats for your password cracking estimates?
> This site shows a 12 character password with salted MD4 and alpha, number
> and spaces (pass phrase) is 23 thousand years and even without numbers is
> 533 years. http://calc.opensecurityresearch.com/  using SHA-1 just about
> doubles that time. If my 12 character pass phrase will take 533 years to
> crack I’m happy with that.
>
>
>
> Mike Cunningham
>
>
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [
> mailto:SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>] *On
> Behalf Of *Steven Alexander
> *Sent:* Monday, October 10, 2016 11:25 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] password length and required reset
>
>
>
> Nick,
>
>
>
> I have some contrary positions.
>
>
>
> What is the eight character minimum based on?  If you only want to prevent
> online guessing (e.g. brute-forcing RDP), eight is probably enough.  If
> you’re trying to protect against offline guessing (i.e. cracking password
> hashes), then eight is not even close to adequate for most systems.  AD
> accounts store passwords using unsalted MD4 which can be guessed at a rate
> of billions of guesses per second.  Many applications using unsalted MD5 or
> SHA-1 which, for password protection, are not much better.  In those cases,
> eight character passwords are very easy to break and many (user-chosen)
> passwords up to about thirteen or fourteen characters can be cracked in a
> reasonable amount of time.  For critical accounts, those with
> administrative privileges and those with access to sensitive data (e.g.
> Payroll), I recommend fifteen characters.
>
>
>
> The research on password expiration shows that regular password changes
> are not helpful.  They have minimal positive impact and encourage users to
> do exactly what you mention: pick a pattern and increment  (“Fall2016!”,
> “Winter2017!”, etc).  The better recommendations are to change passwords
> when an event occurs rather than every XX days and to implement two-factor
> authentication if possible.
>
>
>
> A password vault is a great idea.  Not only does it make it easier to use
> different passwords for different sites/systems, it makes it easier to pick
> strong passwords.
>
>
>
> Regards,
>
>
>
> Steven Alexander
>
> Director of IT Security
>
> Kern Community College District
>
> (661) 336-5111
>
>
>
> *From:* The EDUCAUSE Security Constituent Group Listserv [
> mailto:SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>] *On
> Behalf Of *Nicholas Garigliano
> *Sent:* Sunday, October 9, 2016 7:51 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] password length and required reset
>
>
>
> Hi Mike,
>
>
>
> Some thoughts on password requirements in general:
>
>  - It is common for people to reuse account credentials at multiple sites
> that never require a password change (Amazon, Twitter etc)  If one of the
> sites get hacked and the credentials get dumped, then that increases the
> exposure for your site.  Not to mention the nightmare it creates for the
> user.
>
> - While pass phrases are generally more secure, simple/common ones like
> "Star Wars VII" are not.  You can find these in most on-line cracking
> databases/lists.  Of course, complexity and length are always a trade off
> between usability and administrative overhead (resets etc).
>
> - Current technology has made cracking dumped hashes more feasible for
> your average bad guy.
>
> - Education can help.  Many users, not all as we know, will listen if you
> explain clearly and succinctly why reusing passwords is not in their best
> interest.  Suggesting the use of a password vault I feel is also a good
> idea.
>
>
>
> So my deep thoughts on password's is that you do need a minimum of 8, they
> need to be changed (and not just incremented, i.e. password123) and there
> should be some complexity.  But as usual, it all depends on what you are
> allowed to do or can do in your particular environment.
>
>
> Nick Garigliano, CISSP, GCIH
>
> Network Security Engineer
>
> Enterprise & Network Solutions
>
> Nazareth College
>
> 585 389-2109
>
>
>
> On Fri, Oct 7, 2016 at 3:28 PM, Mike Cunningham <mike.cunningham () pct edu>
> wrote:
>
> We current have a password length rule of 6 with a password expiration of
> 180 days. We are considering changing that to a length of 12 with a
> recommendation to use a pass phrase, and no expiration. Students can want
> to can change their password daily or never. We believe the longer length
> requirement will make the password so much stronger that the password reset
> is no longer needed. This change is for students ONLY. Employees will still
> have a password recent requirement.
>
> Thanks
>
>
> Mike Cunningham
> VP of Information Technology Services/CIO
> Pennsylvania College of Technology