I didn't choose to be a programmer. Somehow, it seemed, the computers chose me. For a long time, that was fine, that was enough; that was all I needed. But along the way I never felt that being a programmer was this unambiguously great-for-everyone career field with zero downsides. There are absolutely occupational hazards of being a programmer, and one of my favorite programming quotes is an allusion to one of them:

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter.

Which reminds me of another joke that people were telling in 2015:

Donald Trump is basically a comment section running for president

Which is troubling because technically, technically, I run a company that builds comment sections.

Here at the tail end of 2017, from where I sit neither of these jokes seem particularly funny to me any more. Perhaps I have lost the capacity to feel joy as a human being? Haha just kidding! ... kinda.

Remember in 2011 when Marc Andreeseen said that "Software is eating the world?"

That used to sound all hip and cool and inspirational, like "Wow! We software developers really are making a difference in the world!" and now for the life of me I can't read it as anything other than an ominous warning that we just weren't smart enough to translate properly at the time. But maybe now we are.

I've said many, many times that the key to becoming an experienced software developer is to understand that you are, at all times, your own worst enemy. I don't mean this in a negative way – you have to constantly plan for and design around your inevitable human mistakes and fallibility. It's fundamental to good software engineering because, well, we're all human. The good-slash-bad news is that you're only accidentally out to get yourself. But what happens when we're infinitely connected and software is suddenly everywhere, in everyone's pockets every moment of the day, starting to approximate a natural extension of our bodies? All of a sudden those little collective social software accidents become considerably more dangerous:

The issue is bigger than any single scandal, I told him. As headlines have exposed the troubling inner workings of company after company, startup culture no longer feels like fodder for gentle parodies about ping pong and hoodies. It feels ugly and rotten. Facebook, the greatest startup success story of this era, isn’t a merry band of hackers building cutesy tools that allow you to digitally Poke your friends. It’s a powerful and potentially sinister collector of personal data, a propaganda partner to government censors, and an enabler of discriminatory advertising.

I'm reminded of a particular Mitchell and Webb skit: "Are we the baddies?"

On the topic of unanticipated downsides to technology, there is no show more essential than Black Mirror. If you haven't watched Black Mirror yet, do not pass go, do not collect $200, go immediately to Netflix and watch it. Go on! Go ahead!

⚠ Fair warning: please DO NOT start with season 1 episode 1 of Black Mirror! Start with season 3, and go forward. If you like those, dip into season 2 and the just-released season 4, then the rest. But humor me and please at least watch the first episode of season 3.

The technology described in Black Mirror can be fanciful at times, but several episodes portray disturbingly plausible scenarios with today's science and tech, much less what we'll have 20 to 50 years from now. These are very real cautionary tales, and some of this stuff is well on its way toward being realized.

Programmers don't think of themselves as people with the power to change the world. Most programmers I know, including myself, grew up as nerds, geeks, social outcasts. Did I ever tell you about the time I wrote a self-destructing Apple // boot disk program to let a girl in middle school know that I liked her? I was (and still am) a terrible programmer, but oh man did I ever test the heck out of that code before copying on to her school floppy disc. But I digress. What do you do when you wake up one day and software has kind of eaten the world, and it is no longer clear if software is in fact an unambiguously good thing, like we thought, like everyone told us … like we wanted it to be?

Months ago I submitted a brief interview for a children's book about coding.

I recently recieved a complimentary copy of the book in the mail. I paged to my short interview, alongside the very cool Kiki Prottsman. I had no real recollection of the interview questions after the months of lead time it takes to print a physical book, but reading the printed page, I suddenly hit myself over the head with the very answer I had been searching my soul for these past 6 months:

In attempting to simplify my answers for an audience of kids, I had concisely articulated the one thing that keeps me coming back to software: to serve man. Not on a platter, for bullshit monetization – but software that helps people be the best version of themselves.

And you know why I do it? I need that help, too. I get tired, angry, upset, emotional, cranky, irritable, frustrated and I need to be reminded from time to time to choose to be the better version of myself. I don't always succeed. But I want to. And I believe everyone else – for some reasonable statistical value of everyone else – fundamentally does, too.

That was the not-so-secret design philosophy behind Stack Overflow, that by helping others become better programmers, you too would become a better programmer. It's unavoidable. And, even better, if we leave enough helpful breadcrumbs behind for those that follow us, we collectively advance the whole of programming for everyone.

I apologize for not blogging much in 2017. I've certainly been busy with Discourse which is actually going great; we grew to 21 people and gave $55,000 back this year to the open source ecosystem we build on. But that's no excuse. The truth is that it's been hard to write because this has been a deeply troubling year in so many dimensions — for men, for tech, for American democracy. I'm ashamed of much that happened, and I think one of the first and most important steps we can take is to embrace explicit codes of conduct throughout our industry. I also continue to believe, if we start to think more holistically about what our software can do to serve all people, not just ourselves personally (or, even worse, the company we work for) — that software can and should be part of the solution.

I tried to amplify on these thoughts in recent podcasts:

	Community Engineering Report with Kim Crayton
	Developer on Fire with Dave Rael
	Dorm Room Tycoon with William Channer

Software is easy to change, but people ... aren't. So in the new year, as software developers, let's make a resolution to focus on the part we can change, and keep asking ourselves one very important question: how can our software help people become the best version of themselves?

It's been a while since I wrote a blog post, I guess in general, but also a blog post about video games. Video games are probably the single thing most attributable to my career as a programmer, and everything else I've done professionally after that. I still feel video games are one of the best ways to learn and teach programming, if properly scoped, and furthermore I take many cues from video games in building software.

I would characterize my state of mind for the last six to eight months as … poor. Not only because of current events in the United States, though the neverending barrage of bad news weighs heavily on me, and I continue to be profoundly disturbed by the erosion of core values that I thought most of us stood for as Americans. Didn't we used to look out for each other, care about each other, and fight to protect those that can't protect themselves?

In times like these, I sometimes turn to video games for escapist entertainment. One game in particular caught my attention because of its meteoric rise in player count over the last year.

That game is Player Unknown's Battlegrounds. I was increasingly curious why it was so popular, and kept getting more popular every month. Calling it a mere phenomenon seems like underselling it; something truly unprecedented is happening here. I finally broke down and bought a copy for $30 in September.

After a few hours in, I had major flashbacks to the first time I played Counter-Strike in 1998. I realized that we are witnessing the birth of an entirely new genre of game: the Battle Royale. I absolutely believe that huge numbers of people will still be playing some form of this game 20 years from now, too.

I've seen the Japanese movie, and it's true that there were a few Battle Royale games before PUBG, but this is clearly the defining moment and game for the genre, the one that sets a precedent for everyone else to follow.

It's hard to explain why Battlegrounds is so compelling, but let's start with the loneliness.

Although you can play in squads (and I recommend it), the purest original form of the game is 100 players, last man standing. You begin with nothing but the clothes on your back, in a cargo aircraft, flying over an unknown island in a random trajectory.

It's up to you to decide when to drop, and where to land on this huge island, full of incredibly detailed cities, buildings and houses – but strangely devoid of all life.

What happened to everyone? Where did they go? The sense of apocalypse is overwhelming. It's you versus the world, but where did the rest of the world go? You'll wander this vast deserted island, scavenging for weapons and armor in near complete silence. You'll hear nothing but the wind blowing and the occasional buzzing of flies. But then, suddenly the jarring pak-pak-pak of gunfire off in the distance, reminding you that other people are here. And they aren't your friends.

the dread of never knowing when another of the 100 players on this enormous island is going to suddenly appear around a corner or over a hill is intense. You'll find yourself wearing headphones, cranking the volume, constantly on edge listening for the implied threat of footfalls. Wait, did I hear someone just now, or was that me? You clench, and wait. I've had so many visceral panic moments playing this game, to the point that I had to stop playing just to calm down.

PUBG is, in its way, the scariest zombie movie I've ever seen, though it lacks a single zombie. It dispenses with the pretense of a story, so you can realize much sooner that the zombies, as terrible as they may be, are nowhere as dangerous to you as your fellow man.

Meanwile, that huge cargo airplane still roars overhead every so often, impassive, indifferent, occasionally dropping supply crates with high powered items to fight over. Airstrikes randomly target areas circled in red on the map, masking footfalls, and forcing movement while raining arbitrary death and terror.

Although the island is huge and you can land anywhere, after a few minutes a random circle is overlaid on the map, and a slowly moving wall of deadly energy starts closing in on that circle. Stay outside that circle at your peril; if you find yourself far on the opposite side of the map from a circle, you better start hunting for a vehicle or boat (they're present, but rare) quickly. These terrordome areas are always shrinking, always impending, in an ever narrowing cone, forcing the remaining survivors closer and closer together. The circles get tighter and deadlier and quicker as the game progresses, ratcheting up the tension and conflict.

Eventually the circle becomes so small that it's impossible for the handful of remaining survivors to avoid contact, and one person, one out of the hundred that originally dropped out of the cargo plane, emerges as the winner. I've never won solo, but I have won squad, and even finishing first out of 25 squads is an unreal, euphoric experience. The odds are so incredibly against you from the outset, plus you quickly discover that 85% of the game is straight up chance: someone happens to roll up behind you, a sniper gets the drop on you, or you get caught in the open with few options. Wrong place, wrong time, game over. Sucks to be you.

You definitely learn to be careful, but there's only so careful you can be. Death comes quickly, without warning, and often at random. What else can you expect from a game mode where there are 100 players but only 1 eventual winner?

There haven't been many Battle Royale games, so this game mode is a relatively new phenomenon. If you'd like to give it a try for free, I highly recommend Fortnite's Battle Royale mode which is 100% free, a near-clone of PUBG, and quite good in its own right. They added their Battle Royale mode well after the fact; the core single player "save the world" gameplay of building stuff and fighting zombie hordes is quite fun too, though a bit shallow. It also has what is, in my opinion, some of the most outstanding visual style I've ever seen in a game – a cool, hyperbolic cartoon mix of Chuck Jones, Sam & Max, and Cloudy with a Chance of Meatballs. It's also delightfully diverse in its character models.

(The only things you'll give up over PUBG are the realistic art style, vehicles, and going prone. But the superb structure building system in Fortnite almost makes up for that. If nothing else it is a demonstration of how incredibly compelling the Battle Royale game mode is, because that part of the game is wildly successful in a a way that the core game, uh, wasn't. Also it's free!)

I didn't intend for this to happen, but to me, the Battle Royale game mode perfectly captures the zeitgeist of the current moment, and matches my current state of mind to a disturbing degree. It's an absolutely terrifying experience of every human for themselves, winner takes all, with impossible odds. There are moments it can be thrilling, even inspiring, but mostly it's brutal and unforgiving. To succeed you need to be exceedingly cautious, highly skilled, and just plain lucky. Roll the dice again, but know that everyone will run towards the sound of gunfire in hopes of picking off survivors and looting their corpses. Including you.

Battle Royale is not the game mode we wanted, it's not the game mode we needed, it's the game mode we all deserve. And the best part is, when we're done playing, we can turn it off.

We've read so many sad stories about communities that were fatally compromised or destroyed due to security exploits. We took that lesson to heart when we founded the Discourse project; we endeavor to build open source software that is secure and safe for communities by default, even if there are thousands, or millions, of them out there.

However, we also value portability, the ability to get your data into and out of Discourse at will. This is why Discourse, unlike other forum software, defaults to a Creative Commons license. As a basic user on any Discourse you can easily export and download all your posts right from your user page.

As a site owner, you can easily back up and restore your entire site database from the admin panel, right in your web browser. Automated weekly backups are set up for you out of the box, too. I'm not the world's foremost expert on backups for nothing, man!

Over the years, we've learned that balancing security and data portability can be tricky. You bet your sweet ASCII a full database download is what hackers start working toward the minute they gain any kind of foothold in your system. It's the ultimate prize.

To mitigate this threat, we've slowly tightened restrictions around Discourse backups in various ways:

• Administrators have a minimum password length of 15 characters.

• Both backup creation and backup download administrator actions are formally logged.

• Backup download tokens are single use and emailed to the address of the administrator, to confirm that user has full control over the email address.

The name of the security game is defense in depth, so all these hardening steps help … but we still need to assume that Internet Bad Guys will somehow get a copy of your database. And then what? Well, what's in the database?

• Identity cookies

  Cookies are, of course, how the browser can tell who you are. Cookies are usually stored as hashes, rather than the actual cookie value, so having the hash doesn't let you impersonate the target user. Furthermore, most modern web frameworks rapidly cycle cookies, so they are only valid for a brief 10 to 15 minute window anyway.

• Email addresses

  Although users have reason to be concerned about their emails being exposed, very few people treat their email address as anything particularly precious these days.

• All posts and topic content

  Let's assume for the sake of argument that this is a fully public site and nobody was posting anything particularly sensitive there. So we're not worried, at least for now, about trade secrets or other privileged information being revealed, since they were all public posts anyway. If we were, that's a whole other blog post I can write at a later date.

• Password hashes

  What's left is the password hashes. And that's … a serious problem indeed.

Now that the attacker has your database, they can crack your password hashes with large scale offline attacks, using the full resources of any cloud they can afford. And once they've cracked a particular password hash, they can log in as that user … forever. Or at least until that user changes their password.

⚠️ That's why, if you know (or even suspect!) your database was exposed, the very first thing you should do is reset everyone's password.

But what if you don't know? Should you preemptively reset everyone's password every 30 days, like the world's worst bigco IT departments? That's downright user hostile, and leads to serious pathologies of its own. The reality is that you probably won't know when your database has been exposed, at least not until it's too late to do anything about it. So it's crucial to slow the attackers down, to give yourself time to deal with it and respond.

Thus, the only real protection you can offer your users is just how resistant to attack your stored password hashes are. There are two factors that go into password hash strength:

1. The hashing algorithm. As slow as possible, and ideally designed to be especially slow on GPUs for reasons that will become painfully obvious about 5 paragraphs from now.

2. The work factor or number of iterations. Set this as high as possible, without opening yourself up to a possible denial of service attack.

I've seen guidance that said you should set the overall work factor high enough that hashing a password takes at least 8ms on the target platform. It turns out Sam Saffron, one of my Discourse co-founders, made a good call back in 2013 when he selected the NIST recommendation of PBKDF2-HMAC-SHA256 and 64k iterations. We measured, and that indeed takes roughly 8ms using our existing Ruby login code on our current (fairly high end, Skylake 4.0 Ghz) servers.

But that was 4 years ago. Exactly how secure are our password hashes in the database today? Or 4 years from now, or 10 years from now? We're building open source software for the long haul, and we need to be sure we are making reasonable decisions that protect everyone. So in the spirit of designing for evil, it's time to put on our Darth Helmet and play the bad guy – let's crack our own hashes!

We're gonna use the biggest, baddest single GPU out there at the moment, the GTX 1080 Ti. As a point of reference, for PBKDF2-HMAC-SHA256 the 1080 achieves 1180 kH/s, whereas the 1080 Ti achieves 1640 kH/s. In a single video card generation the attack hash rate has increased nearly 40 percent. Ponder that.

First, a tiny hello world test to see if things are working. I downloaded hashcat. I logged into our demo at try.discourse.org and created a new account with the password 0234567890; I checked the database, and this generated the following values in the hash and salt database columns for that new user:

hash
93LlpbKZKficWfV9jjQNOSp39MT0pDPtYx7/gBLl5jw=
salt
ZWVhZWQ4YjZmODU4Mzc0M2E2ZDRlNjBkNjY3YzE2ODA=

Hashcat requires the following input file format: one line per hash, with the hash type, number of iterations, salt and hash (base64 encoded) separated by colons:

type   iter  salt                                         hash
sha256:64000:ZWVhZWQ4YjZmODU4Mzc0M2E2ZDRlNjBkNjY3YzE2ODA=:93LlpbKZKficWfV9jjQNOSp39MT0pDPtYx7/gBLl5jw=

Let's hashcat it up and see if it works:

./h64 -a 3 -m 10900 .\one-hash.txt 0234567?d?d?d

Note that this is an intentionally tiny amount of work, it's only guessing three digits. And sure enough, we cracked it fast! See the password there on the end? We got it.

sha256:64000:ZWVhZWQ4YjZmODU4Mzc0M2E2ZDRlNjBkNjY3YzE2ODA=:93LlpbKZKficWfV9jjQNOSp39MT0pDPtYx7/gBLl5jw=:0234567890

Now that we know it works, let's get down to business. But we'll start easy. How long does it take to brute force attack the easiest possible Discourse password, 8 numbers – that's "only" 10⁸ combinations, a little over one hundred million.

Hash.Type........: PBKDF2-HMAC-SHA256
Time.Estimated...: Fri Jun 02 00:15:37 2017 (1 hour, 0 mins)
Guess.Mask.......: ?d?d?d?d?d?d?d?d [8]

Even with a top of the line GPU that's … OK, I guess. Remember this is just one hash we're testing against, so you'd need one hour per row (user) in the table. And I have more bad news for you: Discourse hasn't allowed 8 character passwords for quite some time now. How long does it take if we try longer numeric passwords?

?d?d?d?d?d?d?d?d?d [9]
Fri Jun 02 10:34:42 2017 (11 hours, 18 mins)

?d?d?d?d?d?d?d?d?d?d [10]
Tue Jun 06 17:25:19 2017 (4 days, 18 hours)

?d?d?d?d?d?d?d?d?d?d?d [11]
Mon Jul 17 23:26:06 2017 (46 days, 0 hours)

?d?d?d?d?d?d?d?d?d?d?d?d [12]
Tue Jul 31 23:58:30 2018 (1 year, 60 days)

But all digit passwords are easy mode, for babies! How about some real passwords that use at least lowercase letters, or lowercase + uppercase + digits?

Guess.Mask.......: ?l?l?l?l?l?l?l?l [8]
Time.Estimated...: Mon Sep 04 10:06:00 2017 (94 days, 10 hours)

Guess.Mask.......: ?1?1?1?1?1?1?1?1 [8] (-1 = ?l?u?d)
Time.Estimated...: Sun Aug 02 09:29:48 2020 (3 years, 61 days)

A brute force try-every-single-letter-and-number attack is not looking so hot for us at this point, even with a high end GPU. But what if we divided the number by eight … by putting eight video cards in a single machine? That's well within the reach of a small business budget or a wealthy individual. Unfortunately, dividing 38 months by 8 isn't such a dramatic reduction in the time to attack. Instead, let's talk about nation state attacks where they have the budget to throw thousands of these GPUs at the problem (1.1 days), maybe even tens of thousands (2.7 hours), then … yes. Even allowing for 10 character password minimums, you are in serious trouble at that point.

If we want Discourse to be nation state attack resistant, clearly we'll need to do better. Hashcat has a handy benchmark mode, and here's a sorted list of the strongest (slowest) hashes that Hashcat knows about benchmarked on a rig with 8 Nvidia GTX 1080 GPUs. Of the things I recognize on that list, bcrypt, scrypt and PBKDF2-HMAC-SHA512 stand out.

My quick hashcat results gave me some confidence that we weren't doing anything terribly wrong with the Discourse password hashes stored in the database. But I wanted to be completely sure, so I hired someone with a background in security and penetration testing to, under a signed NDA, try cracking the password hashes of two live and very popular Discourse sites we currently host.

I was provided two sets of password hashes from two different Discourse communities, containing 5,909 and 6,088 hashes respectively. Both used the PBKDF2-HMAC-SHA256 algorithm with a work factor of 64k. Using hashcat, my Nvidia GTX 1080 Ti GPU generated these hashes at a rate of ~27,000/sec.

Common to all discourse communities are various password requirements:

• All users must have a minimum password length of 10 characters.
• All administrators must have a minimum password length of 15 characters.
• Users cannot use any password matching a blacklist of the 10,000 most commonly used passwords.
• Users can choose to create a username and password or use various third party authentication mechanisms (Google, Facebook, Twitter, etc). If this option is selected, a secure random 32 character password is autogenerated. It is not possible to know whether any given password is human entered, or autogenerated.

Using common password lists and masks, I cracked 39 of the 11,997 hashes in about three weeks, 25 from the ████████ community and 14 from the ████████ community.

This is a security researcher who commonly runs these kinds of audits, so all of the attacks used wordlists, along with known effective patterns and masks derived from the researcher's previous password cracking experience, instead of raw brute force. That recovered the following passwords (and one duplicate):

If we multiply this effort by 8, and double the amount of time allowed, it's conceivable that a very motivated attacker, or one with a sophisticated set of wordlists and masks, could eventually recover 39 × 16 = 624 passwords, or about five percent of the total users. That's reasonable, but higher than I would like. We absolutely plan to add a hash type table in future versions of Discourse, so we can switch to an even more secure (read: much slower) password hashing scheme in the next year or two.

bcrypt $2*$, Blowfish (Unix)
  20273 H/s

scrypt
  886.5 kH/s

PBKDF2-HMAC-SHA512
  542.6 kH/s 

PBKDF2-HMAC-SHA256
 1646.7 kH/s 

After this exercise, I now have a much deeper understanding of our worst case security scenario, a database compromise combined with a professional offline password hashing attack. I can also more confidently recommend and stand behind our engineering work in making Discourse secure for everyone. So if, like me, you're not entirely sure you are doing things securely, it's time to put those assumptions to the test. Don't wait around for hackers to attack you — hacker, hack thyself!

When I wrote about The Golden Age of x86 Gaming, I implied that, in the future, it might be an interesting, albeit expensive, idea to upgrade your video card via an external Thunderbolt 3 enclosure.

I'm here to report that the future is now.

Yes, that's right, I paid $500 for an external Thunderbolt 3 enclosure to fit a $600 video card, all to enable a plug-in upgrade of a GPU on a Skull Canyon NUC that itself cost around $1000 fully built. I know, it sounds crazy, and … OK fine, I won't argue with you. It's crazy.

This matters mostly because of 4k, aka 2160p, aka 3840 × 2160, aka Ultra HD.

Plain old regular HD, aka 1080p, aka 1920 × 1080, is one quarter the size of 4k, and ¼ the work. By today's GPU standards HD is pretty much easy mode these days. It's not even interesting. No offense to console fans, or anything.

Late in 2016, I got a 4k OLED display and it … kind of blew my mind. I have never seen blacks so black, colors so vivid, on a display so thin. It made my previous 2008 era Panasonic plasma set look lame. It's so good that I'm now a little angry that every display that my eyes touch isn't OLED already. I even got into nerd fights over it, and to be honest, I'd still throw down for OLED. It is legitimately that good. Come at me, bro.

Don't believe me? Well, guess which display in the below picture is OLED? Go on, guess:

@andrewbstiles if it was physically possible to have sex with this TV I.. uh.. I'd take it on long, romantic walks

— Jeff Atwood (@codinghorror) August 13, 2016

There's a reason every site that reviews TVs had to recalibrate their results when they reviewed the 2016 OLED sets.

In my extended review at Reference Home Theater, I call it “the best looking TV I’ve ever reviewed.” But we aren’t alone in loving the E6. Vincent Teoh at HDTVtest writes, “We’re not even going to qualify the following endorsement: if you can afford it, this is the TV to buy.” Rtings.com gave the E6 OLED the highest score of any TV the site has ever tested. Reviewed.com awarded it a 9.9 out of 10, with only the LG G6 OLED (which offers the same image but better styling and sound for $2,000 more) coming out ahead.

But I digress.

Playing games at 1080p in my living room was already possible. But now that I have an incredible 4k display in the living room, it's a whole other level of difficulty. Not just twice as hard – and remember current consoles barely manage to eke out 1080p at 30fps in most games – but four times as hard. That's where external GPU power comes in.

The cool technology underpinning all of this is Thunderbolt 3. The thunderbolt cable bundled with the Razer Core is rather … diminutive. There's a reason for this.

Is there a maximum cable length for Thunderbolt 3 technology?

Thunderbolt 3 passive cables have maximum lengths.

• 0.5m TB 3 (40Gbps)
• 1.0m TB 3 (20Gbps)
• 2.0m TB 3 (20Gbps)

In the future we will offer active cables which will provide 40Gbps of bandwidth at longer lengths.

40Gbps is, for the record, an insane amount of bandwidth. Let's use our rule of thumb based on ultra common gigabit ethernet, that 1 gigabit = 120 megabytes/second, and we arrive at 4.8 gigabytes/second. Zow.

That's more than enough bandwidth to run even the highest of high end video cards, but it is not without overhead. There's a mild performance hit for running the card externally, on the order of 15%. There's also a further performance hit of 10% if you are in "loopback" mode on a laptop where you don't have an external display, so the video frames have to be shuttled back from the GPU to the internal laptop display.

This may look like a gamer-only thing, but surprisingly, it isn't. What you get is the general purpose ability to attach any PCI express card to any computer with a Thunderbolt 3 port and, for the most part, it just works!

Linus breaks it down and answers all your most difficult questions:

Please watch the above video closely if you're actually interested in this stuff; it is essential. I'll add some caveats of my own after working with the Razer Core for a while:

• Make sure the video card you plan to put into the Razer Core is not too tall, or too wide. You can tell if a card is going to be too tall by looking at pictures of the mounting rear bracket. If the card extends significantly above the standard rear mounting bracket, it won't fit. If the card takes more than 2 slots in width, it also won't fit, but this is more rare. Depth (length) is rarely an issue.

• There are four fans in the Razer Core and although it is reasonably quiet, it's not super silent or anything. You may want to mod the fans. The Razer Core is a remarkably simple device, internally, it's really just a power supply, some Thunderbolt 3 bridge logic, and a PCI express slot. I agree with Linus that the #1 area Razer could improve in the future, beyond generally getting the price down, is to use fewer and larger fans that run quieter.

• If you're putting a heavy hitter GPU in the Razer Core, I'd try to avoid blower style cards (the ones that exhaust heat from the rear) in favor of those that cool with large fans blowing down and around the card. Dissipating 150w+ is no mean feat and you'll definitely need to keep the enclosure in open air … and of course within 0.5 meters of the computer it's connected to.

• There is no visible external power switch on the Razer Core. It doesn't power on until you connect a TB3 cable to it. I was totally not expecting that. But once connected, it powers up and the Windows 10 Thunderbolt 3 drivers kick in and ask you to authorize the device, which I did (always authorize). Then it spun a bit, detected the new GPU, and suddenly I had multiple graphics card active on the same computer. I also installed the latest Nvidia drivers just to make sure everything was ship shape.

• It's kinda ... weird having multiple GPUs simultaneously active. I wanted to make the Razer Core display the only display, but you can't really turn off the built in GPU – you can select "only use display 2", that's all. I got into several weird states where windows were opening on the other display and I had to mess around a fair bit to get things locked down to just one display. You may want to consider whether you have both "displays" connected for troubleshooting, or not.

And then, there I am, playing Lego Marvel in splitscreen co-op at glorious 3840 × 2160 UltraHD resolution on an amazing OLED display with my son. It is incredible.

Beyond the technical "because I could", I am wildly optimistic about the future of external Thunderbolt 3 expansion boxes, and here's why:

• The main expense and bottleneck in any stonking gaming rig is, by far, the GPU. It's also the item you are most likely to need to replace a year or two from now.

• The CPU and memory speeds available today are so comically fast that any device with a low-end i3-7100 for $120 will make zero difference in real world gaming at 1080p or higher … if you're OK with 30fps minimum. If you bump up to $200, you can get a quad-core i5-7500 that guarantees you 60fps minimum everywhere.

• If you prefer a small system or a laptop, an external GPU makes it so much more flexible. Because CPU and memory speeds are already so fast, 99.9% of the time your bottleneck is the GPU, and almost any small device you can buy with a Thunderbolt 3 port can now magically transform into a potent gaming rig with a single plug. Thunderbolt 3 may be a bit cutting edge today, but more and more devices are shipping with Thunderbolt 3. Within a few years, I predict TB3 ports will be as common as USB3 ports.

• A general purpose external PCI express enclosure will be usable for a very long time. My last seven video card upgrades were plug and play PCI Express cards that would have worked fine in any computer I've built in the last ten years.

• External GPUs are not meaningfully bottlenecked by Thunderbolt 3 bandwidth; the impact is 15% to 25%, and perhaps even less over time as drivers and implementations mature. While Thunderbolt 3 has "only" PCI Express x4 bandwidth, many benchmarkers have noted that GPUs moving from PCI Express x16 to x8 has almost no effect on performance. And there's always Thunderbolt 4 on the horizon.

The future, as they say, is already here – it's just not evenly distributed.

I am painfully aware that costs need to come down. Way, way down. The $499 Razer Core is well made, on the vanguard of what's possible, a harbinger of the future, and fantastically enough, it does even more than what it says on the tin. But it's not exactly affordable.

I would absolutely love to see a modest, dedicated $200 external Thunderbolt 3 box that included an inexpensive current-gen GPU. This would clobber any onboard GPU on the planet. Let's compare my Skull Canyon NUC, which has Intel's fastest ever, PS4 class embedded GPU, with the modest $150 GeForce GTX 1050 Ti:

As predicted, that's a 3x-5x stompdown. Mac users lamenting their general lack of upgradeability, hear me: this sort of box is exactly what you want and need. Imagine if Apple was to embrace upgrading their laptops and all-in-one systems via Thunderbolt 3.

I know, I know. It's a stretch. But a man can dream … of externally upgradeable GPUs. That are too expensive, sure, but they are here, right now, today. They'll only get cheaper over time.

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?

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.

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?

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, 15 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:

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.)

If you examine the data, this also turns into an argument in favor of password length. Note that 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.
• They are often wrong, in the sense that the rules chosen 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.

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. Check for 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.

🔔 Clarification

A few people have interpreted this post as "all the other password rules are bullshit, except these four I will now list." That's not what I'm trying to say here.

The idea is to focus on the one understandable, simple, practical, works-in-real-life-in-every-situation rule: length. Users can enter (almost) anything, in proper Unicode, provided it's long enough. That's the one rule to bind them all that we need to teach users: length!

Items #3 through #5 are more like genie-special-exception checks, a you can't wish for infinite wishes kind of thing. It doesn't need to be discussed up front because it should be really rare. Yes, you must stop users from having comically bad passwords that equal their username, or aaaaaaaaaaa or 0123456789, but only as post-entry checks, not as rules that need to be explained in advance.

So TL;DR: one rule. Length. Enter whatever you want, just make sure it's long enough to be a reasonable password.