Coding Horror

26/04/2015 CodingHorror

http://blog.codinghorror.com/ 1/47

CODING HORRORprogramming and human factors

RESOURCESAbout [email protected]

Subscribe in areaderSubscribe via email

Coding Horror has beencontinuously publishedsince 2004

Traffic Stats

Copyright Jeff Atwood 2015Logo image 1993 StevenC. McConnell Proudly published withGhost

23 Apr 2015

Your Password is Too DamnShortI'm a little tired of writing about passwords. But liketaxes, email, and pinkeye, they're not going away anytime soon. Here's what I know to be true, and backedup by plenty of empirical data:

No matter what you tell them, users will alwayschoose simple passwords.

No matter what you tell them, users will re-usethe same password over and over on multipledevices, apps, and websites. If you are luckythey might use a couple passwords instead ofthe same one.

What can we do about this as developers?

Stop requiring passwords altogether, and letpeople log in with Google, Facebook, Twitter,Yahoo, or any other valid form of Internetdriver's license that you're comfortablesupporting. The best password is one you don'thave to store.

Urge browsers to support automatic, built-inpassword generation and management. Ideallysupported by the OS as well, but this requires



cloud storage and everyone on the same page,and that seems most likely to me per-browser.Chrome, at least, is moving in this direction.

Nag users at the time of signup when they enterpasswords that are

Too short: UY7dFd

Lack sufficient entropy: aaaaaaaaa

Match common dictionary words: anteaters1

This is commonly done with an ambient passwordstrength meter, which provides real time feedback asyou type.



If you can't avoid storing the password the first twoitems I listed above are both about avoiding theneed for the user to select a 'new' passwordaltogether then showing an estimation ofpassword strength as the user types is about as goodas it gets.

The easiest way to build a safe password is to make itlong. All other things being equal, the law ofexponential growth means a longer password is abetter password. That's why I was always a fan ofpassphrases, though they are exceptionally painful toenter via touchscreen in our brave new world ofmobile and that is an increasingly critical flaw. Buthow short is too short?

When we built Discourse, I had to select an absoluteminimum password length that we would accept. Ichose a default of 8, based on what I knew from myspeed hashing research. An eight character passwordisn't great, but as long as you use a reasonablevariety of characters, it should be sufficientlyresistant to attack.

By attack, I don't mean an attacker automating a webpage or app to repeatedly enter passwords. There issome of this, for extremely common passwords, butthat's unlikely to be a practical attack on many sitesor apps, as they tend to have rate limits on how oftenand how rapidly you can try different passwords.

What I mean by attack is a high speed offline attackon the hash of your password, where an attackergains access to a database of leaked user data. Thiskind of leak happens all the time. And it will continueto happen forever.



If you're really unlucky, the developers behind thatapp, service, or website stored the password in plaintext. This thankfully doesn't happen too often anymore, thanks to education efforts. Progress! But evenif the developers did properly store a hash of yourpassword instead of the actual password, you betterpray they used a really slow, complex, memoryhungry hash algorithm, like bcrypt. And that theyselected a high number of iterations. Oops, sorry,that was written in the dark ages of 2010 and is nowout of date. I meant to say scrypt. Yeah, scrypt, that'sthe ticket.

Then we're safe? Right? Let's see.

Start with a a truly random 8 characterpassword. Note that 8 characters is the defaultsize of the generator, too. I got U6zruRWL .

Plug it into the GRC password crack checker.

Read the "Massive Cracking Array" result, whichis 2.2 seconds.

Go lay down and put a warm towel over yourface.

You might read this and think that a massive crackingarray is something that's hard to achieve. I regret toinform you that building an array of, say, 24consumer grade GPUs that are optimized for speedhashing, is well within the reach of the average lawenforcement agency and pretty much any smallbusiness that can afford a $40k equipment charge.No need to buy when you can rent plenty of GPUequipped cloud servers these days. Beyond that,



imagine what a motivated nation-state could bring tobear. The mind boggles.

Even if you don't believe me, but you should, theoffline fast attack scenario, much easier to achieve,was hardly any better at 37 minutes.

Perhaps you're a skeptic. That's great, me too. Whathappens when we try a longer random.org passwordon the massive cracking array?

9 characters 2 minutes10 characters 2 hours11 characters 6 days12 characters 1 year13 characters 64 years

The random.org generator is "only" uppercase,lowercase, and number. What if we add specialcharacters, to keep Q*Bert happy?



8 characters 1 minute9 characters 2 hours10 characters 1 week11 characters 2 years12 characters 2 centuries

That's a bit better, but you can't really feel safe untilthe 12 character mark even with a full complement ofuppercase, lowercase, numbers, and specialcharacters.

It's unlikely that massive cracking scenarios will getany slower. While there is definitely a passwordlength where all cracking attempts fall off anexponential cliff that is effectively unsurmountable,these numbers will only get worse over time, notbetter.

So after all that, here's what I came to tell you, thepoor, beleagured user:

Unless your password is at least 12 characters,you are vulnerable.



That should be the minimum password size you useon any service. Generate your password with somekind of offline generator, with diceware, or apassphrase approach whatever it takes, but makesure your passwords are all at least 12 characters.

Now, to be fair, as I alluded to earlier all of this doesdepend heavily on the hashing algorithm that wasselected. But you have to assume that everypassword you use will be hashed with the lamest,fastest hash out there. One that is easy for GPUs tocalculate. There's a lot of old software and systemsout there, and will be for a long, long time.

And for developers:

1. Pick your new password hash algorithmscarefully, and move all your old passwordhashing systems to much harder to calculatehashes. You need hashes that are specificallydesigned to be hard to calculate on GPUs, likescrypt.

2. Even if you pick the "right" hash, you may be



vulnerable if your work factor isn't high enough.Matsano recommends the following:

scrypt: N=2^14,r=8,p=1

bcrypt: cost=11

PBKDF2 with SHA256: iterations=86,000

But those are just guidelines; you have to scalethe hashing work to what's available andreasonable on your servers or devices. Forexample, we had a minor denial of service bugin Discourse where we allowed people to enterup to 20,000 character passwords in the loginform, and calculating the hash on that took, uh several seconds.

Now if you'll excuse me, I need to go change myPayPal password.

Discussion (47 replies)

3 Apr 2015

Given Enough Money, AllBugs Are ShallowEric Raymond, in The Cathedral and the Bazaar,famously wrote

Given enough eyeballs, all bugs are shallow.



The idea is that open source software, by virtue ofallowing anyone and everyone to view the sourcecode, is inherently less buggy than closed sourcesoftware. He dubbed this "Linus's Law".

Insofar as it goes, I believe this is true. When only the10 programmers who happen to work at yourcompany today can look at your codebase, it'sunlikely to be as well reviewed as a codebase that'spublic to the world's scrutiny on GitHub.

However, the Heartbleed SSL vulnerability was aturning point for Linus's Law, a catastrophic exploitbased on a severe bug in open source software. Howcatastrophic? It affected about 18% of all the HTTPSwebsites in the world, and allowed attackers to viewall traffic to these websites, unencrypted... for twoyears.

All those websites you thought were secure? Nope.This bug went unnoticed for two full years.

Two years!



OpenSSL, the library with this bug, is one of themost critical bits of Internet infrastructure theworld has relied on by major companies to encryptthe private information of their customers as ittravels across the Internet. OpenSSL was used onmillions of servers and devices to protect the kind ofimportant stuff you want encrypted, and hiddenaway from prying eyes, like passwords, bankaccounts, and credit card information.

This should be some of the most well-reviewed codein the world. What happened to our eyeballs, man?

In reality, it's generally very, very difficult to fixreal bugs in anything but the most trivial OpenSource software. I know that I have rarely doneit, and I am an experienced developer. Most ofthe time, what really happens is that you tell theactual programmer about the problem and waitand see if he/she fixes it Neil Gunton

Even if a brave hacker communities to read thecode, they're not terribly likely to spot one of thehard-to-spot problems. Why? Few open sourcehackers are security experts. Jeremy Zawodny

The fact that many eyeballs are looking at a pieceof software is not likely to make it more secure. Itis likely, however, to make people believe that itis secure. The result is an open sourcecommunity that is probably far too trusting whenit comes to security. John Viega

I think there are a couple problems with Linus's Law:

1. There's a big difference between usage eyeballsand development eyeballs. Just because you pull



down some binaries in a RPM, or compilesomething in Linux, or even report bugs back tothe developers via their bug tracker, doesn'tmean you're doing anything at all to contributeto the review of the underlying code. Mosteyeballs are looking at the outside of the code,not the inside. And while you can discover bugs,even important security bugs, through usage,the hairiest security bugs require insideknowledge of how the code works.

2. The act of writing (or cut-and-pasting) your owncode is easier than understanding and peerreviewing someone else's code. There is afundamental, unavoidable asymmetry of workhere. The amount of code being churned outtoday even if you assume only a small fractionof it is "important" enough to require seriousreview far outstrips the number of eyeballsavailable to look at the code. (Yes, this isanother argument in favor of writing less code.)

3. There are not enough qualified eyeballs to lookat the code. Sure, the overall number ofprogrammers is slowly growing, but whatpercent of those programmers are skilledenough, and have the right security background,to be able to audit someone else's codeeffectively? A tiny fraction.

Even if the code is 100% open source, utterly missioncritical, and used by major companies in virtuallyevery public facing webserver for customer securitypurposes, we end up with critical bugs thatcompromise everyone. For two years!



That's the lesson. If we can't naturally get enougheyeballs on OpenSSL, how does any other codestand a chance? What do we do? How do we getmore eyeballs?

The short term answer was:

Create more alternatives to OpenSSL forecosystem diversity.

Improve support and funding for OpenSSL.

These are both very good things and necessaryoutcomes. We should be doing this for all the criticalparts of the open source ecosystem people rely on.

But what's the long term answer to the generalproblem of not enough eyeballs on open sourcecode? It's something that will sound very familar toyou, though I suspect Eric Raymond won't be toohappy about it.

Money. Lots and lots of money.



Increasingly, companies are turning to commercialbug bounty programs. Either ones they createthemselves, or run through third party services likeBugcrowd, Synack, HackerOne, and Crowdcurity. Thismeans you pay per bug, with a larger payout thebigger and badder the bug is.

Or you can attend a yearly event like Pwn2Own,where there's a yearly contest and massive prizes, aslarge as hundreds of thousands of dollars, forexploiting common software. Staging a big annualevent means a lot of publicity and interest, attractingthe biggest guns.

That's the message. If you want to find bugs in yourcode, in your website, in your app, you do it the oldfashioned way: by paying for them. You buy theeyeballs.

While I applaud any effort to make things moresecure, and I completely agree that security is abattle we should be fighting on multiple fronts, bothcommercial and non-commercial, I am uneasyabout some aspects of paying for bugs becomingthe new normal. What are we incentivizing, exactly?

Money makes securitybugs go undergroundThere's now a price associated with exploits, and thedeeper the exploit and the lesser known it is, themore incentive there is to not tell anyone about ituntil you can collect a major payout. So you mightwait up to a year to report anything, and meanwhilethis security bug is out there in the wild who knows



who else might have discovered it by then?

If your focus is the payout, who is paying more? Thegood guys, or the bad guys? Should you hold outlonger for a bigger payday, or build the exploit upinto something even larger? I hope for our sake thegood guys have the deeper pockets, otherwise weare all screwed.

I like that Google addressed a few of these concernsby making Pwnium, their Chrome specific variant ofPwn2Own, a) no longer a yearly event but all day,every day and b) increasing the prize money to"infinite". I don't know if that's enough, but it'scertainly going in the right direction.

Money turns securityinto a "me" goal insteadof an "us" goalI first noticed this trend when one or two peoplereported minor security bugs in Discourse, and thenseemed to hold out their hand, expectantly. (At least,as much as you can do something like that in email.)It felt really odd, and it made me uncomfortable.

Am I now obligated, on top of providing a completelyfree open source project to the world, to pay peoplefor contributing information about security bugs thatmake this open source project better? Believe me, Iwas very appreciative of the security bug reporting,and I sent them whatever I could, stickers, t-shirts,effusive thank you emails, callouts in the code andcheckins. But open source isn't supposed to be aboutthe money is it?



Perhaps the landscape is different for closed-source,commercial products, where there's no expectationof quid pro quo, and everybody already pays for theservice directly or indirectly anyway.

No Money? No Security.If all the best security researchers are working onever larger bug bounties, and every major companyadopts these sorts of bug bounty programs, whatdoes that do to the software industry?

It implies that unless you have a big budget, you can'texpect to have great security, because nobody willwant to report security bugs to you. Why would they?They won't get a payday. They'll be lookingelsewhere.

A ransomware culture of "pay me or I won't tell youabout your terrible security bug" does not feel veryfar off, either. We've had mails like that already.

Easy money attracts allskill levelsOne unfortunate side effect of this bug bounty trendis that it attracts not just bona fide programmersinterested in security, but anyone interested in easymoney.

We've gotten too many "serious" security bug reportsthat were extremely low value. And we have to followup on these, because they are "serious", right?Unfortunately, many of them are a waste of time,



because

The submitter is more interested in scaring youabout the massive, critical security implicationsof this bug than actually providing a decentexplanation of the bug, so you'll end up doing allthe work.

The submitter doesn't understand what is andisn't an exploit, but knows there is value inanything resembling an exploit, so submitseverything they can find.

The submitter can't share notes with othersecurity researchers to verify that the bug isindeed an exploit, because they might "steal"their exploit and get paid for it before they do.

The submitter needs to convince you that this isan exploit in order to get paid, so they will arguewith you about this. At length.

The incentives feel really wrong to me. As much as Iknow security is incredibly important, I view theseinteractions with an increasing sense of dreadbecause they generate work for me and the returnsare low.

What can we do?Fortunately, we all have the same goal: makesoftware more secure.

So we should view bug bounty programs as anadditional angle of attack, another aspect of "defense



in depth", perhaps optimized a bit more forcommercial projects where there is ample money.And that's OK.

But I have some advice for bug bounty programs,too:

You should have someone vetting these bugreports, and making sure they are credible, haveclear reproduction steps, and are repeatable,before we ever see them.

You should build additional incentives in yourcommunity for some kind of collaborative worktowards bigger, better exploits. Theseresearchers need to be working together inpublic, not in secret against each other.

You should have a reputation system that buildsup so that only the better, proven contributorsare making it through and submitting reports.

Encourage larger orgs to fund bug bounties forcommon open source projects, not just theirown closed source apps and websites. At StackExchange, we donated to open source projectswe used every year. Donating a bug bountycould be a big bump in eyeballs on that code.

I am concerned that we may be slowly movingtoward a world where given enough money, allbugs are shallow. Money does introduce someperverse incentives for software security, and thoseincentives should be watched closely.

But I still believe that the people who will freely



report security bugs in open source softwarebecause

It is the right thing to do

and

They want to contribute back to open sourceprojects that have helped them, and the world

will hopefully not be going away any time soon.


28 Mar 2015

Toward a Better MarkdownTutorialIt's always surprised me when people, especiallytechnical people, say they don't know Markdown. Doyou not use GitHub? Stack Overflow? Reddit?

I get that an average person may not understandhow Markdown is based on simple old-schoolplaintext ASCII typing conventions. Like when you're*really* excited about something, you naturally putasterisks around it, and Markdown makes thatautomagically italic.

But how can we expect them to know that, if theygrew up with wizzy-wig editors where the only way tomake italic is to click a toolbar button, like an animal?



I am not advocating for WYSIWYG here. While there'scertainly more than one way to make italic, Ipersonally don't like invisible formatting tags and Ifind that WYSIWYG is more like WYCSYCG in practice.It's dangerous to be dependent on these invisibleformatting codes you can't control. And they'reespecially bad if you ever plan to care aboutdifferences, revisions, and edit history. That's why Ilike to teach people simple, visible formatting codes.

We can certainly debate which markup language issuperior, but in Discourse we tried to build a rainbowtool that satisifies everyone. We support:

HTML (safe subset)BBCode (basic subset)Markdown (full)

This makes coding our editor kind of hellishlycomplex, but it means that for you, the user,whatever markup language you're used to willprobably "just work" on any Discourse site youhappen to encounter in the future. But BBCode andHTML are supported mostly as bridges. What weview as our primary markup format, and what wewant people to learn to use, is Markdown.

However, one thing I have really struggled with is thatthere isn't any single great place to refer peopleto with a simple walkthrough and explanation ofMarkdown.



When we built Stack Overflow circa 2008-2009, I puttogether my best effort at the time which became the"editing help" page:

It's just OK. And GitHub has their Markdown Basics,and GitHub Flavored Markdown help pages. They'reOK.

The Ghost editor I am typing this in has an OKMarkdown help page too.



But none of these are great.

What we really need is a great Markdown tutorialand reference page, one that we can refer anyoneto, anywhere in the world, from someone who barelytouches computers to the hardest of hard-corecoders. I don't want to build another one for thesekinds of help pages for Discourse, I want to build onefor everyone. Since it is for everyone, I want toinvolve everyone. And by everyone, I mean you.

After writing about Our Programs Are Fun To Use which I just updated with a bunch of great examplescontributed in the comments, so go check that outeven if you read it already I am inspired by the ideathat we can make a fun, interactive Markdowntutorial together.



So here's what I propose: a small contest to build aninteractive Markdown tutorial and reference, whichwe will eventually host at the home page ofcommonmark.org, and can be freely mirroredanywhere in the world.

Some ground rules:

It should be primarily in JavaScript and HTML.Ideally entirely so. If you need to use a server-side scripting language, that's fine, but try tokeep it simple, and make sure it's somethingthat is reasonable to deploy on a generic Linuxserver anywhere.

You can pick any approach you want, but itshould be highly interactive, and I suggest thatyou at minimum provide two tracks:

A gentle, interactive tutorial for absolutebeginners who are asking "what the heckdoes Markdown even mean?"

A dynamic, interactive reference forintermediates and experts who are askingmore advanced usage questions, like "howdo I make code inside a list, or a list insidea list?"

There's a lot of variance in Markdownimplementations, so teach the most commonparts of Markdown, and cover the optional / lesscommon variations either in the advancedreference areas or in extra bonus sections.People do love their tables and footnotes! Werecommend using a CommonMark compatible



implementation, but it is not a requirement.

Your code must be MIT licensed.

Judging will be completely at the whim of myselfand John MacFarlane. Our decisions will becapricious, arbitrary, probably nonsensical, andabove all, final.

We'll run this contest for a period of one month,from today until April 28th, 2015.

If I have hastily left out any clarifying rules Ishould have had, they will go here.

Of course, the real reward for building is theadmiration of your peers, and the knowledge that anentire generation of people will grow up learningbasic Markdown skills through your contribution to aglobal open source project.

But on top of that, I am offering fabulous prizes!

1. Let's start with my Recommended Reading List. Icount sixteen books on it. As long as you live ina place Amazon can ship to, I'll send you all thebooks on that list. (Or the equivalent value in anAmazon gift certificate, if you happen to have alot of these books already, or prefer that.)

2. Second prize is a CODE Keyboard. This can beshipped worldwide.

3. Third prize is you're fired. Just kidding. Thirdprize is your choice of any three books on myreading list. (Same caveats around Amazon



apply.)

Looking for a place to get started? Check out:

https://github.com/gjtorikian/markdowntutorial.com and http://markdowntutorial.com/ byGaren Torikian

https://github.com/chrisalley/commonmark-website andhttp://chrisalley.github.io/commonmark-website/ by Chris Alley

If you want privacy, you can mail your entries to medirectly (see the about page here for my emailaddress), or if you are comfortable with posting yourcontest entry in public, I'll create a topic ontalk.commonmark for you to post links and gatherfeedback. Leaving your entry in the comments onthis article is also OK.

We desperately need a great place that we can sendeveryone to learn Markdown, and we need your helpto build it. Let's give this a shot. Surprise and amazeus!


9 Mar 2015

Our Programs Are Fun ToUse



These two imaginary guys influenced me heavily as aprogrammer.

Instead of guaranteeing fancy features orcompatibility or error free operation, Beagle Brossoftware promised something else altogether: fun.

Playing with the Beagle Bros quirky Apple II floppiesin middle school and high school, and thesmorgasboard of oddball hobbyist ephemeracollected on them, was a rite of passage for me.



Here were a bunch of goofballs writing terribleAppleSoft BASIC code like me, but doing it for a living and clearly having fun in the process. Apparently,the best way to create fun programs for users is tomake sure you had fun writing them in the first place.

But more than that, they taught me how much morefun it was to learn by playing with an interactive,dynamic program instead of passively readingabout concepts in a book.



That experience is another reason I've alwaysresisted calls to add "intro videos", externaldocumentation, walkthroughs and so forth.

One of the programs on these Beagle Bros floppies,and I can't for the life of me remember which one, orin what context this happened, printed the followingon the screen:

One day, all books will be interactive andanimated.

I thought, wow. That's it. That's what these floppieswere trying to be! Interactive, animated textbooksthat taught you about programming and the Apple II!Incredible.

This idea has been burned into my brain for twentyyears, ever since I originally read it on thatmonochrome Apple //c screen. Imagine a worldwhere textbooks didn't just present a wall of text toyou, the learner, but actually engaged you, playedwith you, and invited experimentation. Right there onthe page.



(Also, if you can find and screenshot the specificBeagle Bros program that I'm thinking of here, I'd bevery grateful: there's a free CODE Keyboard with yourname on it.)

Between the maturity of JavaScript, HTML 5, and thelatest web browsers, you can deliver exactly the kindof interactive, animated textbook experience theBeagle Bros dreamed about in 1985 to billions ofpeople with nothing more than access to the Internetand a modern web browser.

Here are a few great examples I've collected.Screenshots don't tell the full story, so click throughand experiment.

Visualizing Algorithms amazing dynamicvisualizations of several interesting and popularalgorithms.

Parable of the Polygons a playable post on theshape of society.

Sight and Light interactive explanation of 2Dvisibility calculations.

Rolling Shutters an animated explanation ofthe visual glitches introduced in digital camerasby CMOS sensors when taking pictures of fastmoving objects.

Sorting.at a live visualization of commonsorting algorithms.

The future of games history is workplace theft illustrates software history by embedding an



emulated, fully playable version of Wolfenstein3D right in the page.

As suggested in the comments, and also excellent:

Red Blob Games Fun, live demonstrations ofcomputer game algorithm mechanics.

CSS Diner Learn about CSS by interactivelyplaying a game.

MIT's Scratch A popular visual programminglanguage for kids.

Eloquent Javascript This looks like a regularonline book, but click the examples to activate alive sandbox! Type and use the little menu at theupper right (or control-enter) to run the code.

Interpreting Discrete Signals Nice example of asignal processing textbook with interactivegraphs.

Melkman's Algorithm Another approach at atextbook where you must interact to proceed tothe next page.

A Tour of Go Places a live console side by sidewith examples of each concept in the Goprogramming language.

How to Fold a Julia Fractal Another textbook,but this time using lots of detailed JavaScriptanimations that you can step through forwardand back.



How a Handgun Works Visual explanationsusing a bunch of giant, traditional GIFanimations.

507 Mechanical Movements A 1908 primer onmechanical movements, animated for theInternet.

Heres Waldo: Computing the optimal searchstrategy for finding Waldo Good example ofexplaining a visual search algorithm in a blogpost with animated GIFs and graphcs.

(There are also native apps that do similar things; thewell reviewed Earth Primer, for example. But when itcomes to education, I'm not too keen on platformspecific apps which seem replicable in commonJavaScript and HTML.)

In the bad old days, we learned programming byreading books. But instead of reading this dry oldtext:

Now we can learn the same concepts interactively, byreading a bit, then experimenting with live code onthe same page as the book, and watching the resultsas we type.



C'mon. Type something. See what happens.

I certainly want my three children to learn from otherkids and their teachers, as humans have since timebegan. But I also want them to have access to abetter class of books than I did. Books that areeffectively programs. Interactive, animated books thatlet them play and experiment and create, not justpassively read.

I want them to learn, as I did, that our programs arefun to use.


9 Jan 2015

The God LoginI graduated with a Computer Science minor from theUniversity of Virginia in 1992. The reason it's a minorand not a major is because to major in CS at UVa youhad to go through the Engineering School, and I wasabsolutely not cut out for that kind of hardcore math



and physics, to put it mildly. The beauty of a minorwas that I could cherry pick all the cool CS classesand skip everything else.

One of my favorite classes, the one I remember themost, was Algorithms. I always told people myAlgorithms class was the one part of my collegeeducation that influenced me most as a programmer.I wasn't sure exactly why, but a few years ago I had ahunch so I looked up a certain CV and realized thatRandy Pausch yes, the Last Lecture Randy Pausch taught that class. The timing is perfect: University ofVirginia, Fall 1991, CS461 Analysis of Algorithms, 50students.

I was one of them.

No wonder I was so impressed. Pausch was anincredible, charismatic teacher, a testament to theold adage that your should choose your teacher firstand the class material second, if you bother to at all.It's so true.



In this case, the combination of great teacher andgreat topic was extra potent, as algorithms arecentral to what programmers do. Not that we inventnew algorithms, but we need to understand the codethat's out there, grok why it tends to be fast or slowdue to the tradeoffs chosen, and choose the correctalgorithms for what we're doing. That's essential.

And one of the coolest things Mr. Pausch ever taughtme was to ask this question:

What's the God algorithm for this?

Well, when sorting a list, obviously God wouldn'tbother with a stupid Bubble Sort or Quick Sort orShell Sort like us mere mortals, God would justimmediately place the items in the correct order.Bam. One step. The ultimate lower bound oncomputation, O(1). Not just fixed time, either, butliterally one instantaneous step, because you'refreakin' God.

This kind of blew my mind at the time.



I always suspected that programmers becameprogrammers because they got to play God with thelittle universe boxes on their desks. Randy Pauschtook that conceit and turned it into a really usefulway of setting boundaries and asking yourself hardquestions about what you're doing and why.

So when we set out to build a login dialog forDiscourse, I went back to what I learned in myAlgorithms class and asked myself:

How would God build this login dialog?

And the answer is, of course, God wouldn't botherto build a login dialog at all. Every user wouldalready be logged into GodApp the second theyloaded the page because God knows who they are.Authoritatively, even.

This is obviously impossible for us, because God isn'tone of our investors.

But.. how close can we get to the perfect godlike loginexperience in Discourse? That's a noble and worthygoal.

Wasn't it Bill Gates who once asked why the hell



every programmer was writing the same File Opendialogs over and over? It sure feels that way for logindialogs. I've been saying for a long time that the bestlogin is no login at all and I'm a staunch supporter oflogging in with your Internet Driver's licensewhenever possible. So we absolutely support that, ifyou've configured it.

But today I want to focus on the core, basic loginexperience: user and password. That's the defaultuntil you configure up the other methods of login.

A login form with two fields, two buttons, and a linkon it seems simple, right? Bog standard. It is, untilyou consider all the ways the simple act of logging inwith those two fields can go wrong for the user. Let'sthink.

Let the user enter an emailto log in

The critical fault of OpenID, as much as I liked it as anearly login solution, was its assumption that userscould accept an URL as their "identity". This is flat outcrazy, and in the long run this central flawedassumption in OpenID broke it as a future standard.

User identity is always email, plain and simple.What happens when you forget your password? Youget an email, right? Thus, email is your identity. Somepeople even propose using email as the only loginmethod.



It's fine to have a username, of course, but always letusers log in with either their username or their emailaddress. Because I can tell you with 100% certaintythat when those users forget their password, andthey will, all the time, they'll need that email anywayto get a password reset. Email and password arestrongly related concepts and they belong together.Always!

(And a fie upon services that don't allow me to usemy email as a username or login. I'm looking at you,Comixology.)

Tell the user when theiremail doesn't exist

OK, so we know that email is de-facto identity formost people, and this is a logical and necessary stateof affairs. But which of my 10 email addresses did Iuse to log into your site?

This was the source of a long discussion at Discourseabout whether it made sense to reveal to the user,when they enter an email address in the "forgotpassword" form, whether we have that email addresson file. On many websites, here's the sort of messageyou'll see after entering an email address in theforgot password form:



If an account matches [email protected], youshould receive an email with instructions on howto reset your password shortly.

Note the coy "if" there, which is a hedge against allthe security implications of revealing whether a givenemail address exists on the site just by typing it intothe forgot password form.

We're deadly serious about picking safe defaults forDiscourse, so out of the box you won't get exploitedor abused or overrun with spammers. But afterexperiencing the real world "which email did we usehere again?" login state on dozens of Discourseinstances ourselves, we realized that, in this specificcase, being user friendly is way more important thanbeing secure.

The new default is to let people know when they'veentered an email we don't recognize in the forgotpassword form. This will save their sanity, and yours.You can turn on the extra security of being coy aboutthis, if you need it, via a site setting.



Let the user switch betweenLog In and Sign Up any time

Many websites have started to show login and signupbuttons side by side. This perplexed me; aren't theacts of logging in and signing up very differentthings?

Well, from the user's perspective, they don't appearto be. This Verge login dialog illustrates just howclose the sign up and log in forms really are. Checkout this animated GIF of it in action.



We've acknowledged that similarity by having eitherform accessible at any time from the two buttons atthe bottom of the form, as a toggle:

And both can be kicked off directly from any page viathe Sign Up and Log In buttons at the top right:



Pick common words

That's the problem with language, we have so manywords for these concepts:

Sign InLog InSign UpRegisterJoin Create AccountGet StartedSubscribe

Which are the "right" ones? User research data isn'tconclusive.

I tend to favor the shorter versions when possible,mostly because I'm a fan of the whole brevity thing,but there are valid cases to be made for eachdepending on the circumstances and userpreferences.



Sign In may be slightly more common, though Log Inhas some nautical and historical computing basisthat makes it worthy:

A couple of years ago I did a survey of topwebsites in the US and UK and whether theyused sign in, log in, login, log on, or someother variant. The answer at the time seemed tobe that if you combined log in and login, itexceeded sign in, but not by much. Ive alsonoticed that the trend toward sign in isincreasing, especially with the most popularservices. Facebook seems to be a log in hold-out.

Work with browserpassword managers

Every login dialog you create should be tested towork with the default password managers in

Internet ExplorerChromeFirefoxSafari



At an absolute minimum. Upon subsequent logins inthat browser, you should see the username andpassword automatically autofilled.

Users rely on these default password managers builtinto the browsers they use, and any proper modernlogin form should respect that, and be designedsensibly, e.g. the password field should have type="password" in the HTML and a name that'sreadily identifable as a password entry field.

There's also LastPass and so forth, but I generallyassume if the login dialog works with the built inbrowser password managers, it will work with thirdparty utilities, too.

Handle common usermistakes

Oops, the user is typing their password with capslock on? You should let them know about that.



Oops, the user entered their email [email protected] instead of [email protected]? [email protected] instead of [email protected]?You should either fix typos in common emaildomains for them, or let them know about that.

(I'm also a big fan of native browser "revealpassword" support for the password field, so theuser can verify that she typed in or autofilled thepassword she expects. Only Internet Explorer and Ithink Safari offer this, but all browsers should.)

Help users choose betterpasswords

There are many schools of thought on forcinghelping users choose passwords that aren'tunspeakably awful, e.g. password123 and iloveyouand so on.

There's the common password strength meter, whichupdates in real time as you type in the passwordfield.



It's clever idea, but it gets awful preachy for my tasteson some sites. The implementation also leaves a lotto be desired, as it's left up to the whims of the siteowner to decide what password strength means. Onesite's "good" is another site's "get outta here withthat Fisher-Price toy password". It's frustrating.

So, with Discourse, rather than all that, I decided we'ddefault on a solid absolute minimum passwordlength of 8 characters, and then verify the passwordto make sure it is not one of the 10,000 mostcommon known passwords by checking its hash.



Don't forget the keyboard

I feel like keyboard users are a dying breed at thispoint, but for those of us that, when presented with alogin dialog, like to rapidly type

[email protected] , tab , p4$$w0rd , enter

please verify that this works as it should. Taborder, enter to submit, etcetera.

Rate limit all the things

You should be rate limiting everything users can do,everywhere, and that's especially true of the logindialog.

If someone forgets their password and makes 3attempts to log in, or issues 3 forgot passwordrequests, that's probably OK. But if someone makesa thousand attempts to log in, or issues a thousand



forgot password requests, that's a little weird. Why, Imight even venture to guess they're possibly nothuman.

You can do fancy stuff like temporarily disableaccounts or start showing a CAPTCHA if there are toomany failed login attempts, but this can easilybecome a griefing vector, so be careful.

I think a nice middle ground is to insert standardpauses of moderately increasing size after repeatedsequential failures or repeated sequential forgotpassword requests from the same IP address. Sothat's what we do.

Stu I forgot

I tried to remember everything we went throughwhen we were building our ideal login dialog forDiscourse, but I'm sure I forgot something, or couldhave been more thorough. Remember, Discourse is100% open source and by definition a work inprogress so as my friend Miguel de Icaza likes tosay, when it breaks, you get to keep both halves. Feelfree to test out our implementation and give us yourfeedback in the comments, or point to otherexamples of great login experiences, or cite otherhelpful advice.

Logging in involves a simple form with two fields, alink, and two buttons. And yet, after reading all this,



I'm sure you'll agree that it's deceptively complex.Your best course of action is not to build a logindialog at all, but instead rely on authentication froman outside source whenever you can.

Like, say, God.


Page 1 of 279 Older Posts

Coding Horror

Documents

Transcript of Coding Horror