There’s a few ways they make sites safe:
# Don’t let your control panels face the internet
If you’re Netflix, you only want people who work AT Netflix (i.e. work in the building) to be able to access customer data for support purposes, so you set up your web server to say “only allow access to the control panel if the request is coming from these specific addresses”
This is also how remotely accessing databases work. When setting up a database, you need to explicitly say “these specific addresses can connect”, because if you say “let anyone connect”, someone can sit there at home and keep trying and trying until they get in
# Throttling
A great website will limit how many times you can try something. If you accidentally let a control panel face the internet, you may be saved(-ish) if you lock people out if they put in the wrong password too many times. Windows does this if you put your password in wrong too many times. Sometimes you need to restart your computer, or it’ll sit there for a minute before saying “wrong password”, so that you’re not able to try a million passwords a minute.
# Code reviews, version control, automated testing and building
Big companies don’t just build their site and plonk it on the internet. They usually use something like GitHub or BitBucket or Gitlab to collaborate on code. A typical workflow might look like this:
* Alice at Example Inc. creates a GitHub project called “example.com website” and builds the first version of the website
* Bob, also at Example Inc. wants to add a page to the website, so he makes a copy of the “example.com website” on his own GitHub account
* Bob then adds the page he wants, then asks to merge his code with Alice’s code
* Alice looks at Bob’s code (she can see everything he added, removed and changed) and either approves the merge, rejects it, or asks Bob to make changes and resubmit.
In this example, Alice is reviewing the code, but for larger projects, several people might need to review the code before it’s merged in.
Many companies also do automated testing. Sometimes it’ll be just people writing simple tests. For example you might have a test that says “Add a new customer to the database with the ID 1234, then check the database for a customer with the ID 1234. If one is found, the test passes” so that you’ll never be able to deploy code that breaks the “add new customer” core feature.
Sometimes, especially with things like mobile and desktop apps, the app will be automatically built when someone pushes some code. For example if you’re writing a calculator app and someone wants to merge some code, Gitlab might automatically take that code and build it into an actual app in a testing environment, then run it. If the app is successfully built, then the project maintainer knows the changes don’t break the app entirely.
# Bug Bounties
Some companies will pay you very good money if you report a major bug to them. For example, Apple will pay you up to a million dollars if you can show them a bug that lets a hacker bypass Lockdown Mode and steal sensitive data without touching the phone. Google will pay you $31,000 for various bugs such as escaping a secure sandbox
# Code auditors and security testers
Some companies employ auditors and security testers. Their job is to comb through code line-by-line to find flaws in it that code reviews may have missed, and to actually try breaking stuff (e.g. by sending a 6 digit customer ID when the app only expects 4 digits, or sending a picture instead of sending a 4 digit ID).
They may also look at all the employees in a company and what permissions they have, and point out any people who have permissions that are way too broad.
# Encryption, hashing etc.
This is the core of your question. Companies don’t (or rather, shouldn’t) store your password or credit card in plain text. They should (or rather, MUST) encrypt or hash your data to keep it secure.
Encryption is reversible, like putting a document in a safe, then retrieving that document but only if you have the passcode. Hashing is (under ideal conditions) non-reversible, and is perfect for storing credit cards and passwords
Let’s pretend you have the password “Password1234”. You send that to Google, and it’s run through a special mathematical function (e.g. [MD5](https://www.md5hashgenerator.com/)), to get **ef749ff9a048bad0dd80807fc49e1c0d** back.
If someone gets hold of that **ef749…** string, they won’t know how to make that string using MD5, because there are 457 TRILLION possible 8 character passwords if you’re just using 4 lowercase letters, two numbers and two special characters.
A great website will salt the hash as well. A salt is just random data added to the end of the password to make it more secure.
So for example if User A had the password “Hello” and User B also had the password “Hello”, if you hashed the two passwords, they’d be exactly the same which means you crack one, you’ve cracked the other. But if you add random data to each person’s password, e.g. “Hello%TYUHJ” and “Hello&@*$RH”, then the two hashes would be totally different and an attacker wouldn’t know that User A and User B shared the same password.
===========================
So tl;dr: Don’t let the internet access your internal control panels, set up good procedures so all code you write gets checked over by other people, and never ever EVER store sensitive data in plain text. Oh, and if your budget allows it, reward people who responsibly disclose bugs and security issues in your app / site.
Latest Answers