A simple suggestion:

If, after reading this (or even before) you say 'I don't want the hassle', we do provide SaaS where we handle all the headaches of HTTPS, and we provide you access to your backups so you can keep 'your' data.. Contact sales@maintenanceconnection.ca if you want more info on switching to our SaaS. While we obviously can't give details, if you have specific security clearance requirements we have past and current experience meeting government including military security requirements.

But … now, let's ignore running on our SaaS servers, and talk to those of you that are running your own servers … we do everything we can to keep your hassle level at a minimum. But as of 2019 - you are required to be HTTPS even on an intranet, no options remain.

Officially we only support HTTPS

Effective January 1st 2017, we only support HTTPS officially for all our products and installs.

We are aware our software in many cases runs or mostly runs on HTTP, but that is an unsupported environment (meaning if we are able to help we bill by the hour, not that we will ignore your email or phone call!)

The summary of this document is: You should be using HTTPS for everything.

Several features in MCe/MCxLE the browsers require we use HTTPS. Our GIS plugin for MRO uses things like get current location and they are not permitted in HTTP.

With HTTP we periodically (it felt like about once a week) had customers who ran into problems with 'corrupted' code (data) that was downloaded. To avoid this we did everything we could to minimize the number of times that code was downloaded to the devices. Since we switched to HTTPS years ago, we have not once had an issue that appears to be based on files being corrupted during the download.

No Hijacking, when running from many airports for example, supposedly 'safe' hijacking ¹ would break our application. By switching to HTTPS, we never have 'safe' or any other type of hijacking. So on top of the much less often 'malicious' hijacking, HTTPS stops any hijacking. I put 'safe' and 'malicious' in quotes, because really – any hijacking is malicious, the airport etc.., ones just try to convince people that theirs is safe even though they break many web applications.

History

Our servers

We have since the last millennium had the OPTION for customers to go to HTTPS.

We offered it as a 'low cost' option on our hosted servers – but interestingly, no one was willing to pay even the $100 we offered on one of our servers – and that didn't even recover our costs of doing it!

In 2015 we started converting all sites on the internet over to HTTPS.

The browsers started taking features away from HTTP

In December 2015 Chrome started to TAKE AWAY features that we used and only permit them on 'secure' connections where secure means: HTTPS or internal network only.

In 2016 a couple more went away.

For example: Get current location (used heavily in our GIS) became an HTTPS 'only' feature (no longer available in HTTP) disappeared with Chrome 50. This same feature went to HTTPS only months later with Safari 10. (As of Sept 2017 Firefox has it listed as going away 'soon'.)

In January 2017 Chrome 56 started warning people when password or credit card fields were on HTTP instead of HTTPS. (With Brave and Opera following a few weeks later after Chrome took all the flak)

In October 2017 a lot of irritating red warnings started showing up in Chrome 62. https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html

If after reading my comments below you don't immediately switch everything to HTTPs, check out this site: https://doesmysiteneedhttps.com/

We had been 'unofficially' recommending people on HTTP try the Brave and Opera browsers, and the reports we got back were good … until August 2017 … Both those browsers decided to copy Chrome's restrictions suddenly with no warning, so they now require HTTPS to run properly as well. I'm sure other major browsers will be following suite (other than IE).

Edge makes your life annoying if you run on HTTP. While they didn't take the features away, they now ask you in a dialog box 'hidden' at the bottom of the page every single time you try to use these features. (Once you are on HTTPS they only ask once per site, then they stop warning/annoying you.)

Major sites are headed this way, many are already there. https://transparencyreport.google.com/https/top-sites

WHY would anyone use HTTPS?

To eliminate data corruption between the device and the server.

To get rid of irritants: More browsers are starting to show more warnings if you don't use HTTPS, and most are promising to keep tightening down the screws until they have forced everyone to switch to HTTPS. So one reason is to stop having users see the browser warnings.

The only major browser not doing is the browser that has been abandoned by Microsoft: IE 11.

Some features (like accessing the camera for barcode reading) are, in all browsers still being kept up to date, only permitted or made easier with HTTPS, this is especially true of new features they are adding, or in the case of IE, missing because it is no longer being upgraded.

With current HTTPS it is very unlikely than in the next decade anyone will be able to decode your transmissions, and as it becomes possible to decode them, there will be newer ways to decrypt that will make it more difficult to decrypt new transmissions.

Reasons I've heard to NOT use or not 'bother' using HTTPS:

Hint, if you don't want to read the technical details, here is a summary of ALL the items below:

"I don't want to bother using HTTPS, but I don't have a good reason, just excuses."

HTTPS is slower than HTTP.

No it is not, it is usually faster! HTTP/2 is ONLY implemented on HTTPS. HTTPS/2 over HTTPS is faster than any HTTP alternative.

And even without HTTP/2 Obviously there is a slight overhead using HTTPS. But to be completely realistic, compared to 2000, the overhead is very close to zero. So in our opinion, you should not make your decision based on that anymore. Back in the early days, yes, HTTPS was slower and that was a good reason to ignore HTTPS unless you really needed it, but that was then, that's not with today's computers. Basically the power required to convert has not materially changed, but everything else around it has!

https://istlsfastyet.com/

HTTPS and everything around it isn't perfect.

Agreed, so I assume you don't wear your seatbelt either? HTTPS is by far the best we have. The only better way to keep data secret is to not write it down and don't tell anyone. (Tell someone a secret and it is, by definition, not a secret.)

But it costs SO much to get HTTPS.

A few years ago, sure. Today: You can get large multi-site ones from letsencrypt.org for free.

HTTPS is so hard to install and maintain:

Some still are, but letsencrypt's are much easier than most were a few years ago.

And recovering from a hack is much harder.

It's too complicated, all this HTTP, HTTPS, TLS – people can't even decide what to call it.

Do you know how your door lock works? Do you refuse to have a lock installed on your door because you don't understand how it works internally? There are people who understand the details, and most who simply don't care. Not protecting yourself because you don't want to know all the details is silly. Yes, someone has to know them all, but all you (or someone in IT) has to know is how to install and maintain it, and there is lots of guides for that. If you really want to know the details go to a locksmith course or a HTTPS course depending on which you want to know more about.

I've given a practical, as non-technical as I could, definition of terms in the Terminology section to make you feel more comfortable.

Our server is on the intranet, not exposed to the internet so there is zero risk.

Well, if you are a Nuclear plant, and you have a Faraday cage around all your computer equipment, and you have physically disabled the USB ports etc.., you are probably fairly safe as long as you are extremely careful and if you don't care about data corruption.

But if you don't have a Faraday cage and you don't care about data corruption:

• Do you trust that your hardware manufacturer has zero flaws? (Think of all the problems with Iot, Internet of Things, devices like fridges that it turns out they made a mistake and there is no way to fix it other than buy a new fridge)
• Do you trust that your firewalls and other software have zero flaws?
• Do you really not want the new features that the newer browsers let us give you?

OK, maybe a public web site is easy to set and maintain HTTPS, but setting HTTPS on an Intranet is hard.

Yes it is harder than an internet. You have to:

• Work with a company that provides certificates to people like you or
• issue yourself a certificate
• then add yourself as a trusted issuing source on each computer that will access that server and the certificate

Basically the exact same process as is required in order to setup a TLS proxy or encrypted logging/interception.

If you (your IT department) doesn't have the competency to set this up there are many people you can hire to do it or help you do it for a fee. We can do it at an hourly rate with/for you, but most of the time you would be better working with someone who does it for a living. We also have another document that discusses it in a bit more detail – read that first.

But if you don't do it, you will never get the benefits of the newer browser features and someday, when you are hacked, you will have left yourself a much easier target.

So using the above techniques – ANYONE can make a dangerous site look safe by using TLS proxies.

Only if you let your users modify their computers to trust the dangerous TLS. It requires a human to ALLOW it, and if your users don't have administrator (root level) privileges, they can't even do that.

Hackers can still impersonate a website that is HTTPS, so why bother?

Sure, they can try to impersonate it. But browsers wills warn your users that they are using a mismatched or invalid certificate. And if the hacker doesn't even try to use HTTPS, newer browsers will mark the fake pages as insecure. As browsers get more visible about calling all HTTP bad, your users will get used to having the safety of seeing they are protected and when they see a warning lock they are much more likely to notice and take action to protect themselves. But if you allow them to always (or often) see those warnings, you will teach your users to ignore the warnings and when a real attack happens on a different site, your users will be trained by you to trust the hacker. It will be your fault.

We hash encrypt our passwords

Wonderful. And if you only ever use HTTPS to transmit them, you will at least be one step better. But wait … if you set up HTTPS to do that – why not get the PERFORMANCE and SAFETY benefits of HTTPS on ALL your pages?

And if you are using HTTP to collect the passwords – you have now made it possible for ANYONE between you and the user to connect into your system and do anything that user could.

It should be someone else's responsibility, like the browser.

OK, whatever. The government says it is illegal to kill people. So it is their responsibility to make sure no one kills you. Does that mean you are going to walk up to a drug dealer who is holding a gun and tell him you are going to report him to the police? And no, this is not a silly comparison (I have a friend who made that exact real mistake before realizing how stupid he was being, fortunately he realized his mistake from a far enough distance and neither of the 2 bullets hit him, no I'm not making that up.) If you don't use HTTPS you really are being that foolish.

HTTP doesn't conceal the content size, allowing attackers to find out some info.

So, would you tell your passwords to someone who hates you just because some sites have leaked the initials of your name? And good news… TLS 1.3 and HTTP/2 have ways that they obfuscate this as well with padding frames.

My site is secure with HTTP. No one has ever hacked me.

That is what one company reported to Mozilla, and a few minutes later their site was hacked, passwords exposed to the world and then their database was deleted. Read all about it here https://arstechnica.com/security/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page-insecure/ and then go to the site that did the complaining … they are fulling running in HTTPS now. Now, I do NOT condone the actions of the people that hacked them. But the fact they could be hacked and totally taken down in minutes shows that they just had not yet been attacked, not that they had good security without HTTPS.

HTTPS encryption is good now … but what about if someone stores my transmissions and decrypts them in say 10 years?

The NSA in the US is reported to be sniffing out billions of pieces of HTTPS data per hour and storing them in their computers. My understanding is their goal is that, around 2025, computers will be SO much faster that they will be able to go back and un-encrypt all the data they saw go through the internet today. The idea being that things that currently would take current computers billions (using the 1,000,000,000 North American definition of billions) of years will then take only hours.

Is this realistic? Well, on December 9th 2015, it was reported that initial testing of a Google/NASA quantum computer made their test programs run literally more than 100 million times faster than a PC. That's 100,000,000 times faster. And given the theory of quantum computer, it is not unrealistic to think that that could become billions or literally trillions of times faster in the next 10 years. With numbers this large, I don't care which definition of billion or trillion you use! And decryption is listed as one of the best things for quantum computers. So if on 2015 computers it would take a billion years, it is feasible that in 2025 it could take literally fractions of a second to decrypt. Again, this means that something that would currently take billions of years to do on the fastest computers currently available in stores today might realistically take a fraction of a second to do on computers from your local computer store 10 years from now, or at least on a computer that the NSA can get their hands on.

A little mind boggling isn't it! Maybe it will be 2035, maybe 2025, but likely it is coming.

So the conclusion some people make is: Why go through the hassle of using HTTPS if my transmissions will be decrypted in 10 years anyway? My answers are:

• Your data is protected from transmission errors now. That alone is worth it. But then…
• there is no guarantee that the computers WILL be able to decrypt it in 10 years, it may take 15 or 20 or 500.
• nly what was stored can be decrypted – so do you really care if the NSA can decrypt it in that time? Very few other – even government – organizations could store that much data for 10+ years. So the chances of your transmissions being stored by anyone who can harm you (unless you are doing something so illegal that the NSA can 'harm' you) is very slim.
• most of your sensitive data today won't matter if someone sees it anyway. And if you are worried, if it is going to be transmitted, HTTPS today is still your safest option other than never putting it on any computer, but that is not an HTTP vs HTTPS decision.
• isn't having it protected/secured for about 10 years' worth the tiny effort? And as computer power goes up, the encryptions will get better and we'll use it as it becomes commonly available.

HTTPS affects SEO

Yup, in a positive way. It might affect your ratings – in particular, if your competitors haven't switched to HTTPS you will now rank higher, and if they switched to HTTPS first, you will finally have a chance to catch up to them.

My site doesn't collect any data

HTTPS keeps your URL's headers and contents of all transferred pages as confidential as is currently possible.

But someone is suing all people with HTTPS

No, that isn't true. They sued a targeted short list. But if you take that you shouldn't use any products from Apple, Linux, Android, Microsoft or Samsung or many others because all of them have been sued for one thing or another.

Fine, I'll setup HTTPS, but I'll maintain HTTP for those people that want HTTP.

Ah, and who is that? I can see maintaining HTTP on some TEST sites ONLY for very special purposes, usually temporary. But why on earth would you maintain HTTP when you can just redirect everyone to HTTPS? If you REALLY want to let people type in HTTP:// etc.., fine, leave port 80 open but redirect EVERY request (web sites like IIS make this easy) to port 443 then close the connection to port 80. Someday, when all browsers are as smart as Brave, we can get rid of port 80 entirely. (I'll update this when all the major browsers will automatically look for an address on HTTPS:// even when the user types in or pastes HTTP:// then we'll also close port 80 and we'll tell our grandchildren about the wild west days of the internet where we let everyone who wanted to know our password and secret information easy access as long as they had a server sitting anywhere on the internet.)

HTTPS doesn't conceal the DNS lookup.

And so you want to make everything public info because one little piece is? DNS and HTTP or DNS and HTTPS are not the same thing. HTTPS protects your content (and a bit more), not the public DNS record information.

Phishing sites use HTTPS

So because they are doing the smart thing, you want to go unprotected? Because they are not getting the security warnings, you want to teach your users to ignore security warnings? Because they are protecting their information, you want to make yours easy to be hacked and modified (noting as above that airlines etc.., routinely edit your pages when showing to your users if you use HTTP)

HTTPS makes it harder for me to inject my code into other people's pages, so I want to slow down the conversion to HTTPS, so I am setting an example by not securing my stuff.

Good luck. The rest of the world is (in 2017) moving very quickly to HTTPS. If you are an airline etc.., you are soon going to lose the ability to corrupt HTTP pages as the rest of us switch to HTTPS. The only ones left will be you and a few others that don't mind if their pages are routinely corrupted by others.

There is no sensitive data on my site anyway.

Your site is a risk to other people – do you really want the legal liability? Just because your site is nicely stored safely on your computer in your office building doesn't mean the data won't be transmitted through all sorts of other people's equipment. And while the NSA may only be collecting data from your site, it doesn't mean that someone else along the line isn't trying to inject code, pictures, ad content or downright nasty stuff into your pages to make it look like you put them there. And these are not just theoretical 'horrible' people, Nice people like airports, airlines, countries. Check out these links if you think I'm being overly dramatic or talking theory:

https://twitter.com/konklone/status/598696478018666496https://www.theregister.co.uk/AMP/2015/01/06/gogo_ssl/https://twitter.com/troyhunt/status/691166196268417024https://twitter.com/paul_irish/status/871431848957575168https://gist.github.com/ryankearney/4146814

https://citizenlab.ca/2015/04/chinas-great-cannon/

https://gist.github.com/Jarred-Sumner/90362639f96807b8315b/

https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/

HTTPS prevents ALL of the above.

It means your customers/users/technicians can know that the content has not been tampered with anyone outside those that have control of the server.

It means you are painting a target on anything of yours that is HTTPS. Keeping everything in HTTPS means you are not alerting a hacker, the NSA or anyone else to what does contain data worth trying to hack. (Have you ever noticed when someone starts whispering – that is when everyone tries to eavesdrop?) You'd almost be better to encrypt everything EXCEPT your critical data – keep people looking in the wrong space. But I said ALMOST – it is not really better.

Does Maintenance Connection Canada run EXCLUSIVELY in HTTPS or do we do some HTTP?

We ONLY use HTTP for testing and we do most of our testing in HTTPS. Because we do have a few customers left that pay us by the hour so they can run in HTTP, and that means we have to support them. So from time to time various things we have will temporarily run in HTTP. But other than for testing, no we run 100% in HTTPS. We do NOT run ANY customer data on our SaaS servers in HTTP. The last thing we did as HTTP was the MC Service Requestor, but we created a patch for that in August 2017 (we started to try to find a patch as soon as a customer pointed out that the MC 7 service requestor couldn't run in HTTPS)

So what do we recommend?

We now recommend you use HTTPS, specifically the modern version which is HTTPS/TLS using SHA-2. (So the newest version, TLS 1.2 minimum) See also Terminology below, most people incorrectly refer to this as HTTPS-SSL/TLS or have no idea what jargon to use.

Our new software is ONLY routinely tested on HTTPS, it is very rare that we test on HTTP other than to make sure that all our HTTP refuses to run as HTTP and forces you to HTTPS. But we do 'by the hour' to support a few remaining customers that have not made the switch.

Our hosted (SaaS/Cloud) servers are already converted.

We consider it 'mandatory' for all new customers on the internet.

The following video link has some good information on why we didn't use/recommend HTTPS all the time in early 2015 and why we do recommend it now. https://youtu.be/0JioB7rNpvI

Rational

There are several reasons why we do this now and why we didn't 'strongly encourage' it and why we didn't previously (2015) offer it 'for free' as part of our hosting service.

• Let's Encrypt has made, HTTPS very practical and easy to manage and ' free'.
  • The process is much simpler than the traditional ways of getting and renewing HTTPS
  • It's free. (This is more significant once you understand that the best practices security advice is to purchase a new certificate every x weeks or months so that you never have 'stale' certificates after things like the heartbleed virus. Following this advice prior to 2016 meant that you would be looking at thousands of dollars per year PER sub-domain. And given none of our customers were willing to pay even a small fee per month for HTTPS – following the best practices for HTTPS was impractical.)
• As 'flaws' are found in software, these two factors above mean you can have short term HTTPS licenses that don't perpetuate flaws (like happened when the heartbleed virus was going around.)
• Browsers are getting more and more obnoxious about sites that don't use HTTPS and some major browser vendors are promising to keep going in that direction until everyone is irritated enough to make the move, but in early 2015 they weren't irritating at all, and they gave no 'incentive' to make the move.
• Previous certificates were mostly SHA1 which in 2015 was found to be 'reasonable' for someone like NSA to decrypt. The cost in time and effort, and the older browsers in use out there simply make SHA2 either difficult or impossible.

Reasons to use HTTPS with SHA-2:

• To keep passwords etc.., secret on the internet
• To stop intermediary sites (such as your user's Internet connection service providers) adding ads etc.., to your page. The MITM (Man In The Middle) scenario – both benign like hopefully your service provider is, and dangerous – like people writing phishing injections.

Reasons people give to do EVERYTHING HTTPS, not just pages with secure data

• A network adversary can rewrite links on the page so that even if the payment pages are HTTPS, a user would be tricked into going to a non-HTTPS version (or a fake site).
  • A comparatively low-effort version of this is automated SSL stripping, described by Moxie Marlinspike.
  • http://www.thoughtcrime.org/software/sslstrip/
• Bruce Schneier "urges people to 'make surveillance expensive again' by encrypting as much Internet data as possible…Every time you use encryption, you're protecting someone who needs to use it to stay alive." (my emphasis) He gives details explaining why he feels this is the case – and I essentially agree with his arguments.
• Some people don't like having corporations like Google following them and 'learning' about them to make decisions based on what they see you doing on the internet. I don't mind this one, but I know more people do than don't so I'm willing to 'help them out'.

Limitations

What it won't prevent:

• Phishing (fake sites getting you to type in your id/password). The LoginHub 1 click does help with that because they know they never have to do this so the users will be more suspicious when asked. BUT … HTTPS will stop phishing in cases like where someone added a 'login' button into the Google Apps home page which is a phishing INJECTION. See above for more details on why, while it won't stop Phishing, using HTTPS makes it more likely that you users won't be tricked by a phishing site, and using HTTP means you are training your users to be more easily tricked.
• People who have access to your database directly (sys-admins, db admins, users with high security in your application(s) etc..,) Some reports suggest that over 80% of data theft is by people with high level access in the organization.

Terminology

I am giving 'practical' definitions of each of these terms, I am aware that technically the definition of most of these is a little more complicated. But the purpose here is to give a simple, practical, understanding.

HTTPS:

HyperText Transfer Protocol Secure. Most people think that the S stands for SSL. It is a method of transmitting data between a server and a browser.

SSL:

Secure Sockets Layer. A term coined by Netscape (later AOL). This is a proprietary term and there are legal issues regarding its use.

Many people use it regardless and so it is the commonly known 'name' of TLS– indeed, more people probably use the SSL to refer incorrectly to TLS than there are people who use the term TLS correctly!

Some people say SSL/TLS to refer to TLS but they say SSL/TLS because they know most people mistakenly think it is SSL and have no idea what TLS is.

HTTP/2:

A newer version of HTTP that is ONLY available when using HTTPS that is for most sites MUCH faster than HTTP.

• In other words HTTP/2 on HTTPS is way faster than HTTP even though HTTPS means there is extra processing time to do/undo the encryption.
• HTTP/2 is NOT HTTP, HTTP/2 only works in HTTPS

And YES it is confusing that it says 'HTTP/2' but doesn't run on HTTP only on HTTPS. Unfortunately computer people aren't good at making things easy to understand. The reason is that /2 has nothing to do with the S part of it, but everyone has agreed to only implement the /2 on HTTPS and never on HTTP. So /2 could have been done on HTTP, everyone just agreed not to.

TLS:

Transport Layer Security. A term coined primarily to avoid legal issues with Netscape who invented SSL.

TLS 1.0 is often called 'SSL 3.1" which for this document is a true enough statement.

Encoding:

Transforming data using a scheme that, if someone else knows just the scheme they can decode it.

Encoding can be used for making data smaller, or just 'for convenience' or to make casual observation impractical.

For the technically minded: ASCII or EBCDIC are both encoding methods.

Sometimes encoding with 'secret schemes' is used as a replacement for encryption. See encrypting.

Decoding:

The opposite of Encoding, taking something that is encoded and turning it into its original form. Requires only knowledge of the encoding scheme.

So if you find the code, that's all you need to decode, most encoding/decoding the owners try (usually unsuccessfully) to hide the code that does the encoding and decoding.

Encrypting:

Similar to Encoding but using something like a password so knowing the scheme to Encrypt is not enough – you need additional information to decrypt.

Encrypting is typically used to make data secret/hard to read

Decrypting:

The opposite of Encrypting, taking something that is encrypted and turning it into its original form. Requires knowledge of the Encryption scheme and encryption key(s). (Note: In some cases, the decryption key is different from the encryption key.)

Encryption/Decryption means if you find the code, you still need more info to decrypt it. Unlike encode/decode, the best Encrypting/Decrypting algorithms are publically known on purpose so that flaws can be detected and fixed.

Hashing:

For data integrity. Being able to quickly get a high degree of confidence that the data is 'correct' and 'uncorrupted'.

For data comparison. Being able to compare two large sets of data by seeing if their hash's are the same.

You can combine Encryption with Hashing depending on your use case.

Many systems will store your password as a hash. So where we can, for example, we would hash the password on the client, then send the hash to be compared. Why would we do that? Because a lot of people use the same password on many servers, so only being able to see the hash means you are unlikely to be able to use their password on another system.

Most 'hashes' do not contain enough information to regenerate the source and this means that many 'hashes' are one way. In these cases, even if you know how the hash is being created, you can't generate the source data. In human terms: we can validate you typed the correct password, but we can't figure out what your password is.

Hashes of small amounts of data are often done in a computationally 'expensive'² way to make it harder to derive, in part because today's computers are very fast. For example, for a 4 digit pin you might hash it 1000 times, meaning you hash it, then hash the hash, then hash the hash, by doing it 1000 times the 'cost' to someone to calculate guesses is very high, nearly 1000x's the work – but, with today's computers, the cost (computer time) is only a portion of a second so it is reasonable when you know the input data to do the calculation 1000 times.

A password is often an exception where the hash is often longer than the password so, at least in theory, there could be enough data to generate the source.

Requirements and preferences:

• The same input must always produce the same output.
• For many hashes it is desirable that any 'small' modification in the input should result in a drastic change to the hash, but there is no technical requirement for that and it depends on the purpose of your hash whether this is important. Clearly if your purpose is the password use case above you would want this to be true.
• It should be very unlikely or impossible for 2 different source inputs to produce the same hash.
• It must be impossible for 2 different, but almost the same, inputs to produce the same hash.
• It normally should be impossible to go from the output to derive the input.

The goal is to make the amount of computer time so high that it can't reasonably be guessed. So, for example, you might have heard that SHA-1 took at one point in time '1 billion years of computer time' to crack. That meant that if you had 1 billion computers working on cracking a specific set of data, it would take 1 year to figure out how to break one person's transmissions. But then a better algorithm brought it down to only 100million years, and by 2017 with certain computers (GPU's if you care) were much faster and because google figured out a better cracking algorithm, instead of 1 billion years of computer time it only 'cost' 6500 years in computer time or 110 years in GPU. And while you may not have 6500 years, someone like this author has one box that has 64 computers in it in my house and the computer I'm typing thee manuals on has a board with a hundred GPU's on it, so I could now do it in 1 year. I'm not in the business of trying to crack, but if I took all the boards with GPU's sitting around my office on the problem I'd get the crack down to weeks. So someone in the business of cracking, for say $10,000 could get it down to hours or minutes. Hence the claims that SHA-1 is no longer secure.

Throw in quantum computing experiments, and you are down to mere seconds or sub second to crack SHA-1.

For a pin hash, among other reasons, because you have to physically have the computer (cell phones are computers) to try the pin, it is considered very secure https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-why-pin-is-better-than-password. In addition, we allow alpha-numeric for our PINs and we allow PINs of any length (subject to a minimum – 4 is typically the minimum among companies that use PIN's. Some also set a maximum of 4 – and you understand the frustration if you are from Canada or the US and have ever travelled oversees with a debit card that has a 6 digit pin only to find out that many 'foreign' ATM machines only accept a 4 digit pin. Anyway, by hashing it 1000 times, it is sufficiently costly to calculate to make calculations impractical given how PINs are used.