Newsletter Subject

Coding Horror

From

codinghorror.com

Email Address

noreply+feedproxy@google.com

Sent On

Fri, Mar 10, 2017 01:56 PM

Email Preheader Text

--------------------------------------------------------------- Posted: 10 Mar 2017 03:16 AM PST Of

[Coding Horror]( --------------------------------------------------------------- [Password Rules Are Bullshit]( Posted: 10 Mar 2017 03:16 AM PST Of the many, many, many [bad things about passwords](, you know what the worst is? Password rules. If we don't solve the password problem for users in my lifetime I am gonna haunt you from beyond the grave as a ghost [pic.twitter.com/Tf9EnwgoZv]( — Jeff Atwood (@codinghorror) [August 11, 2015]( Let this pledge be duly noted on the permanent record of the Internet. I don't know if there's an afterlife, but I'll be finding out soon enough, and I plan to go out mad as hell. The world is absolutely awash in terrible password rules: - [Dumb Password Rules]( - [Bad Password Policies]( - [Password Requirements Shaming]( But I don't need to tell you this. The more likely you are to use a truly random password generation tool, like us über-geeks are supposed to, the more likely you have suffered mightily – and daily – under this regime. Have you seen the classic XKCD [about passwords](? [To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.] We [can certainly debate]( whether "correct horse battery staple" is a viable password strategy or not, but the argument here is mostly that length matters. [That's What She Said] No, seriously, it does. I'll go so far as to say [your password is too damn short](. These days, given the state of cloud computing and GPU password hash cracking, any password of 8 characters or less is perilously close to no password at all. So then perhaps we have one rule, that passwords must not be short. A long password is much more likely to be secure than a short one … right? What about this four character password? ✅🐎🔋🖇️ What about this eight character password? æ­£ç¡®é©¬ç”µæ± è®¢ä¹¦é’‰ Or this (hypothetical, but all too real) seven character password? [@codinghorror]( I'm sorry but your password must contain 1 char each from: Arabic, Chinese, Thai, Korean, Klingon, Wingdings and an emoji — Finley Creative (@FinleyCreative) [March 3, 2016]( You may also be surprised, if you paste the above four Unicode emojis into your favorite login dialog (go ahead – try it), to discover that it … isn't in fact four characters. Oh dear. "💩".length === 2 Our old pal Unicode [strikes again](. As it turns out, even the simple rule that "your password must be of reasonable length" … ain't necessarily so. Particularly if we stop thinking like [Ugly ASCII Americans](. And what of those nice, long passwords? Are they always secure? aaaaaaaaaaaaaaaaaaa 0123456789012345689 passwordpassword usernamepassword Of course not, because have you met any users lately? [I changed all my passwords to ] They consistently ruin every piece of software I've ever written. Yes, yes, I know you, Mr. or Ms. über-geek, know all about the concept of entropy. But expressing your love of entropy as terrible, idiosyncratic password rules … - must contain uppercase - must contain lowercase - must contain a number - must contain a special character … is a spectacular failure of imagination in a world of Unicode and Emoji. As we built [Discourse](), I discovered that [the login dialog was a remarkably complex piece of software](, despite its surface simplicity. The primary password rule we used was also the simplest one: length. Since I wrote that, we've already increased our minimum password default length from 8 to 10 characters. And if you happen to be an admin or moderator, we decided the minimum has to be even more, 12 characters. I also advocated checking passwords against the 100,000 most common passwords. If you look at [10 million passwords from data breaches in 2016](, you'll find the top 25 most used passwords are: 123456 123456789 qwerty 12345678 111111 1234567890 1234567 password 123123 987654321 qwertyuiop mynoob 123321 666666 18atcskd2w 7777777 1q2w3e4r 654321 555555 3rjs1la7qe google 1q2w3e4r5t 123qwe zxcvbnm 1q2w3e Even this data betrays some ASCII-centrism. The numbers are the same in any culture I suppose, but I find it hard to believe the average Chinese person will ever choose the passwords "password", "quertyuiop", or "mynoob". So this list has to be customizable, localizable. (One interesting idea is to search for common shorter password matches inside longer passwords, but I think this would cause too many false positives.) Also of note: only 5 of the top 25 passwords are 10 characters, so if we require 10 character passwords, we've already reduced our exposure to the most common passwords by 80%. I saw this originally when I gathered millions and millions of leaked passwords for Discourse research, then filtered the list down to just those passwords reflecting our new minimum requirement of 10 characters or more. It suddenly became a tiny list. (If you've done similar common password research, please do share your results in the comments.) I'd like to offer the following common sense advice to my fellow developers: 1. Password rules are bullshit - They don't work. - They heavily penalize your ideal audience, people that use real random password generators. Hey guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure. - They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure. - Are often wrong, in the sense that they are grossly incomplete and/or insane, per the many shaming links I've shared above. - Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read [this 2016 NIST password rules recommendation](. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". 2. Enforce a minimum Unicode password length One rule is at least easy to remember, understand, and enforce. This is the proverbial one rule to bring them all, and in the darkness bind them. - It's simple. Users can count. Most of them, anyway. - It works. The data shows us it works; just download any common password list of your choice and group by password length. - The math doesn't lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password. - Accept that even this one rule isn't inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable. A 20 character password can be ridiculously insecure. - If you don't allow (almost) every single unicode character in the password input field, you are probably doing it wrong. - It's a bit of an implementation detail, but make sure maximum password length is reasonable as well. 3. Check for common passwords As I've already noted, the definition of "common" depends on your audience, and language, but it is a terrible disservice to users when you let them choose passwords that exist in the list of 10k, 100k, or million most common known passwords from data breaches. There's no question that a hacker will submit these common passwords in a hack attempt – and it's shocking how far you can get, even with aggressive password attempt rate limiting, using [just the 1,000 most common passwords](. - 1.6% have a password from the top 10 passwords - 4.4% have a password from the top 100 passwords - 9.7% have a password from the top 500 passwords - 13.2% have a password from the top 1,000 passwords - 30% have a password from the top 10,000 passwords Lucky you, there are millions and millions of real breached password lists out there to sift through. It is sort of fun to do data forensics, because these aren't hypothetical synthetic Jack the Ripper password rules some bored programmer dreamed up, these are real passwords used by real users. Do the research. Collect the data. Protect your users from themselves. 4. Check for basic entropy No need to get fancy here; pick the measure of entropy that satisfies you deep in the truthiness of your gut. But remember you have to be able to explain it to users when they fail the check, too. [entropy visualized]( I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters. And that's what we do as of the current beta version of Discourse. But I'd love your ideas in the comments, too. The simpler and clearer the better! 5. Reject special case passwords I'm embarrassed to admit that when building the Discourse login, [as I discussed in The God Login](, we missed two common cases that you really have to block: - password equal to username - password equal to email address 🤦 If you are using Discourse versions earlier than 1.4, I'm so sorry and please upgrade immediately. Similarly, you might also want to block other special cases like - password equal to URL or domain of website - password equal to app name In short, try to think outside the password input box, like a user would. [advertisement] Building out your tech team? [Stack Overflow Careers]( helps you hire from the largest community for programmers on the planet. We built our site with developers like you in mind. You are subscribed to email updates from [Coding Horror](. To stop receiving these emails, you may [unsubscribe now](. Email delivery powered by Google Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

Marketing emails from codinghorror.com

View More
Sent On

20/04/2020

Sent On

12/09/2019

Sent On

20/08/2019

Sent On

30/05/2019

Sent On

17/02/2019

Sent On

22/10/2018

Email Content Statistics

Subscribe Now

Subject Line Length

Data shows that subject lines with 6 to 10 words generated 21 percent higher open rate.

Subscribe Now

Average in this category

Subscribe Now

Number of Words

The more words in the content, the more time the user will need to spend reading. Get straight to the point with catchy short phrases and interesting photos and graphics.

Subscribe Now

Average in this category

Subscribe Now

Number of Images

More images or large images might cause the email to load slower. Aim for a balance of words and images.

Subscribe Now

Average in this category

Subscribe Now

Time to Read

Longer reading time requires more attention and patience from users. Aim for short phrases and catchy keywords.

Subscribe Now

Average in this category

Subscribe Now

Predicted open rate

Subscribe Now

Spam Score

Spam score is determined by a large number of checks performed on the content of the email. For the best delivery results, it is advised to lower your spam score as much as possible.

Subscribe Now

Flesch reading score

Flesch reading score measures how complex a text is. The lower the score, the more difficult the text is to read. The Flesch readability score uses the average length of your sentences (measured by the number of words) and the average number of syllables per word in an equation to calculate the reading ease. Text with a very high Flesch reading ease score (about 100) is straightforward and easy to read, with short sentences and no words of more than two syllables. Usually, a reading ease score of 60-70 is considered acceptable/normal for web copy.

Subscribe Now

Technologies

What powers this email? Every email we receive is parsed to determine the sending ESP and any additional email technologies used.

Subscribe Now

Email Size (not include images)

Font Used

No. Font Name
Subscribe Now

Copyright © 2019–2025 SimilarMail.