Oct 10, 2017

The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1d!

Bill Burr’s 2003 report recommended using numbers, obscure characters and capital letters and updating regularly—he regrets the error

The man who wrote the book on password management has a confession to make: He blew it.

Back in 2003, as a midlevel manager at the National Institute of Standards and Technology, Bill Burr was the author of “NIST Special Publication 800-63. Appendix A.” The 8-page primer advised people to protect their accounts by inventing awkward new words rife with obscure characters, capital letters and numbers—and to change them regularly.

The document became a sort of Hammurabi Code of passwords, the go-to guide for federal agencies, universities and large companies looking for a set of password-setting rules to follow.

The problem is the advice ended up largely incorrect, Mr. Burr says. Change your password every 90 days? Most people make minor changes that are easy to guess, he laments. Changing Pa55word!1 to Pa55word!2 doesn’t keep the hackers at bay.

Also off the mark: demanding a letter, number, uppercase letter and special character such as an exclamation point or question mark—a finger-twisting requirement.

“Much of what I did I now regret,” said Mr. Burr, 72 years old, who is now retired.

In June, Special Publication 800-63 got a thorough rewrite, jettisoning the worst of these password commandments. Paul Grassi, an NIST standards-and-technology adviser who led the two-year-long do-over, said the group thought at the outset the document would only require a light edit.

“We ended up starting from scratch,” Mr. Grassi said.

The new guidelines, which are already filtering through to the wider world, drop the password-expiration advice and the requirement for special characters, Mr. Grassi said. Those rules did little for security—they “actually had a negative impact on usability,” he said.

Long, easy-to-remember phrases now get the nod over crazy characters, and users should be forced to change passwords only if there is a sign they may have been stolen, says NIST, the federal agency that helps set industrial standards in the U.S.

Amy LaMere had long suspected she was wasting her time with the hour a month it takes to keep track of the hundreds of passwords she has to juggle for her job as a client-resources manager with a trade-show-display company in Minneapolis. “The rules make it harder for you to remember what your password is,” she said. “Then you have to reset it and it just makes it take longer.”

When informed that password advice is changing, however, she wasn’t outraged. Instead, she said it just made her feel better. “I’m right,” she said of the previous rules. “It just doesn’t make sense.”

Academics who have studied passwords say using a series of four words can be harder for hackers to crack than a shorter hodgepodge of strange characters—since having a large number of letters makes things harder than a smaller number of letters, characters and numbers.

In a widely circulated piece, cartoonist Randall Munroe calculated it would take 550 years to crack the password “correct horse battery staple,” all written as one word. The password Tr0ub4dor&3— a typical example of password using Mr. Burr’s old rules—could be cracked in three days, according to Mr. Munroe’s calculations, which have been verified by computer-security specialists.

Mr. Burr, who once programmed Army mainframe computers during the Vietnam War, had wanted to base his advice on real-world password data. But back in 2003, there just wasn’t much to find, and he said he was under pressure to publish guidance quickly.

He asked the computer administrators at NIST if they would let him have a look at the actual passwords on their network. They refused to share them, he said, citing privacy concerns.

“They were appalled I even asked,” Mr. Burr said.

With no empirical data on computer-password security to be found, Mr. Burr leaned heavily on a white paper written in the mid-1980s—long before consumers bought DVDs and cat food online.

The published guidelines were the best he could do.

“In the end, it was probably too complicated for a lot of folks to understand very well, and the truth is, it was barking up the wrong tree,” said Mr. Burr.

Nevertheless, NIST’s password advice became widely influential, not just within the federal government but on corporate networks, websites and mobile devices.

Collectively, humans spend the equivalent of more than 1,300 years each day typing passwords, according to Cormac Herley, a principal researcher at Microsoft Corp. His company once followed the Burr code for passwords, but no more.

The biggest argument against Mr. Burr’s prescriptions: they haven’t worked well. “It just drives people bananas and they don’t pick good passwords no matter what you do,” Mr. Burr said.

The past decade has seen a data-breach boom. Hackers have stolen and posted online hundreds of millions of passwords from companies such as MySpace, LinkedIn and Gawker Media.

Those postings have given researchers the data they need to take a hard look how people’s passwords fare against the tools hackers used to break them. Their conclusion? While we may think our passwords are clever, they aren’t. We tend to gravitate toward the same old combinations over and over.

Back in 2003, Mr. Burr didn’t have the data to understand this phenomenon. Today, it is obvious to people like Lorrie Faith Cranor. After years of studying terrible concoctions, she put 500 of the most commonly used passwords on a blue and purple shift dress she made and wore to a 2015 White House cybersecurity summit at Stanford University.

Adorned with the world’s most common passwords—princess, monkey, iloveyou and others that are unprintable here—the dress has prompted careful study, and embarrassment.

“I’ve had people look at it and they’re like, ‘Oh, I’d better go change my passwords,” said Ms. Cranor, a professor at Carnegie Mellon University.

The NIST rules were supposed to give us randomness. Instead they spawned a generation of widely used and goofy looking passwords such as Pa$$w0rd or Monkey1! “It’s not really random if you and 10,000 other people are doing it,” said Mr. Herley, the Microsoft researcher.

Mr. Grassi, who rewrote NIST’s new password guidelines, thinks his former colleague Mr. Burr is being a little bit hard on himself over his 2003 advice.

“He wrote a security document that held up for 10 to 15 years,” Mr. Grassi said. “I only hope to be able to have a document hold up that long.”

Sep 7, 2016

Password Strength Meters

Here is an interesting take on Password Strength Meters for websites (which are usually bad, but they do remind the user that good passwords are important).

https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/ 

TL;DR – (1) Complex character sets are not as good as long passwords. (2) Use of keyboard patterns and common words, even leetspeak, make (shorter) passwords weaker.

Code here:

https://github.com/dropbox/zxcvbn

And here is a nice implementation using their code:

https://www.my1login.com/resources/password-strength-test/ 


Oct 1, 2012

ASP.NET ASPX Pre-compile Errors

MS Visual Studio, by default, does not compile a project’s ASPX/ASCX pages until runtime (via IIS Just-In-Time compiler).  Unfortunately, the IIS JIT compiler is very forgiving, ignoring some syntax errors, missing custom tag libraries, un-handled events, etc.  Therefore, these types of errors may exist in ASPX pages even though the web page “works”.


This Visual Studio Post-Build Event will show these hidden ASPX errors in the Error Window when a normal REBUILD ALL is performed.


Framework 2.0, 3.0, 3.5:
VS2010 -> Project -> Properties -> Build Events -> Post-build event command line:
"%systemroot%\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler" -errorstack -c -v "$(TargetName)" -p "$(ProjectDir)\"


Framework 4.0, 4.5:
VS2010 -> Project -> Properties -> Build Events -> Post-build event command line:
"%systemroot%\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler" -errorstack -c -v "$(TargetName)" -p "$(ProjectDir)\"


64-bit Framework 2.0, 3.0, 3.5:
VS2010 -> Project -> Properties -> Build Events -> Post-build event command line:
"%systemroot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_compiler" -errorstack -c -v "$(TargetName)" -p "$(ProjectDir)\"


64-bit Framework 4.0, 4.5:
VS2010 -> Project -> Properties -> Build Events -> Post-build event command line:
"%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_compiler" -errorstack -c -v "$(TargetName)" -p "$(ProjectDir)\"