There are numerous techniques for cracking passwords, and already cracked passwords are floating around the web waiting to be used by threat actors. How can we reduce the risks concerning passwords?

As a result of recent data breaches like the Dropbox and LinkedIn breaches in 2012 and the Kickstarter breach in February 2014, passwords and login details were leaked to the public. Sites like https://haveibeenpwned.com have been established to let users search for their e-mail address to see if their password has been pawned. Post-breach analysis have shown that many people use simple passwords that are vulnerable to dictionary attacks. Also many people re-use their credentials on several sites, increasing the risk if their password is compromised.

With this in mind, how can we reduce the risks concerning passwords ?

Passphrases instead of passwords

Passwords should be avoided for several reasons. Many people tend to choose (if possible) simple dictionary words that are easily cracked by openly available hacker tools. Secondly, the usual requirements for passwords are numbers, capital/non-capital and special characters, making the passwords unmemorable for humans. This may lead to passwords being written on a paper or a post-it, which again leads to less secure passwords.

A better solution is to use a passphrase. A passphrase is longer than a password and can be a sentence with spaces in between words, like for instance "Correct horse battery staple". The main reason for using passphrases is that they are easy to remember while still being hard to guess or crack. Passphrases may also satisfy requirements like punctuations and capital/non-capital letters as those appear natural in a sentence. Leading Operating Systems like Windows, Mac and Linux all support longer passphrases.

Avoid frequent password changes

A common security principle has been to enforce password updates periodically. This means that users have had to update their password typically every 60 or 90 days. Furthermore, historic passwords were stored to prevent users from re-using old passwords. Although this was measures to enhance security, recent studies have shown that forcing password updates may be counterproductive to security. With periodic password updates, users tend to rewrite old passwords by changing just a letter or a number, and some users write down their different passwords on a paper. None of these methods lead to better password security.

The National Institute of Standards and Technology (NIST) provide guidelines for best practice security. Their recent guidelines for handling passwords recommend memorized secrets not to be changed arbitrarily. NIST recommends password changes only in the event of compromise.

Two-factor authentication

Although you are using a strong passphrase, your credentials can still be compromised. Using the same passphrase on different sites increases your risk in the event of such compromise. A recommended way to lower the risk is to enable "two-factor authentication" (2FA).

2FA means that the user provides two pieces of evidence for authentication, typically a password/passphrase (first factor) and a code (second factor) received in a different channel. In the event of a compromised password/passphrase, your account is still safe as the attacker does not have access to your code.

All major service providers like Google, Microsoft, Apple, Facebook, and many more, have support for 2FA. For deeper understanding of 2FA, read Hans Kristian Henriksen's article.

Best practice for passwords

JavaScript is a fast-paced language in regards to adaption and growth. By the end of 2017 there was an estimated 9.7 million JavaScript developers, which suggest that we might have passed 10 million in 2018.

With that many developers it might not come as a surprise that NPM (the node package manager) is the largest collection of open-source libraries on the planet (over 836,000 packages and counting - so go publish one!). TC-39 has also vowed to develop the ECMAScript standard and publish a new version every year with new features. This means that keeping up with the amount of activity in the JavaScript community can become a daunting task, but not impossible! The best way of staying up-to-date is to follow developers and JavaScript enthusiasts on Twitter. So don't get lost in the JavaScript jungle, use this list of recommendations as your guide for starters:

@BrendanEich
Hopefully you've already heard about Brendan Eich. He is the creator of JavaScript!

@dan_abramov
Dan Abramov works for Facebook. He created and co-authored Redux.

@mjackson
Micheal Jackson, not the late great king of pop, but the king/co-author of react-router and react training.

@getify
Kyle Simpson. If you haven't already, you should definitely read the YDKJS (You Don't Know JS) book series written by Kyle. But first, follow him on twitter!

@_ericelliott
Eric Elliot, author of "Programming JavaScript Applications", JavaScript instructor, editor of JavaScript Scene, and developer.

@rauschma
Axel Rauschmayer, the man behind the 2ality blog and also author of many books about JavaScript.

@sophiebits
Sophie Alpert, engineer at Facebook working on React.

@kentcdodds
Kent C. Dodds, instructor at egghead.io and engineer at PayPal.

@wSokra
Tobias Koppers, the creator of Webpack. You can read more about bundling your app with Webpack (or Parcel) here, if you haven't already.

Not enough for you? Head over to this tweet by Dan Abramov for more JavaScript people to follow!

Don't get lost in the JavaScript jungle

Server-side rendering of your frontend application can be indispensable for some cases, but... is it worth the effort?

Server-side rendering - worth the effort?

In simple terms, server-side rendering (SSR) in React enables you to render your app to static html on a server, which can then be returned to a browser. There are numerous ways of setting up the full SSR experience - and for those, Google is your friend. The basic setup however, is fairly straightforward.

On a Node.js server, simply render your app by:

This renders a React element to an HTML string, which can then be returned as HTML in a response body. However, when loaded by a browser, this will only be static content without any JavaScript included. To enable JavaScript to be executed, the client-side code needs to be combined with the server-side output. Enter .hydrate():

This works in the same way as render(), but basically fills in the gaps of the html created by your SSR by adding the event listeners. And there you go, you got your App hooked up with SSR!

Hot or not?

As with all the big questions in life, the answer is that very unsatisfying... "it depends". So let's take a closer look at how it stacks up.

Benefit 1: First Meaningful Paint

SSR gets you to first meaningful paint faster. Or at least, potentially. Instead of having to download and then render the JavaScript in your browser, HTML is downloaded directly. For the user, they get the feeling that the site loads quicker.

That said, it isn't always a clear cut victory: getting the first byte takes more time as server-side rendering is slower to execute. Pre-rendered HTML is also generally bigger than your JavaScript bundle, so also takes longer time to download.

There are also other ways to achieve the same effect without having to go down the SSR road. Using loading animations, optimising your code and build packages for speed, pre-rendering tools (etc.) can also improve the perception among your users of a blazing fast site.

Benefit 2: Search Engine Optimisations

Perhaps the most important use-case for SSR is search engine optimisation (SEO). If the entire app was client-side rendered, traditionally, all the web-crawler could "see" was an empty page. Nowadays, many search engines have the ability to render JavaScript in the crawler. But, and this is important, not all of them can, nor do they do it all the time. Google for example have JavaScript bots, but these are not run as often. So the general rule of thumb is - make it as easy as you can for the bots, and both the bots and your marketing department will love you.

Again, as an alternative to SSR, you could look to pre-render your site using tools like react-snap and react-static in order to support you with your SEO performance.

Benefit 3: Sharing pages on social media

When you share a link on a social media platform (Facebook, Slack, etc), the link is rendered to show a preview of the page. The platforms only preview whatever html is on the page and do not render the javascript, which means that SSR could be useful. That said, the content for the preview is typically retrieved from the meta-tags of the html. So to be able to preview your page, you might not need the full SSR experience - but rather just a selected amount of meta-tags, such as title, description, image etc.

Do or don't?

There is broad agreement in the community that SSR can be hard and a real pain to do well and to maintain, in particular if you have a data rich application with many routes.

Essentially, you will be pushed to duplicate a lot of features to get it working correctly on the server-side. Think things like how to manage your redux store, CSS-in-JS, internationalisation, and so forth. In addition, one of the key challenges about SSR is how to know what data your view needs and how to get that data, before rendering it. Furthermore, there is the challenge on how to best handle cookies, redirects, and non 200 HTTP statuses. You also need to set up the infrastructure to render your app for you.

Of course, these are all challenges that are solvable - it just requires development time and effort. And it then becomes a matter of deciding whether the benefits outweigh the costs.

19-Dec

Today's posts

Best practice for passwords

Don't get lost in the JavaScript jungle

Server-side rendering