I am learning web dev and I don’t understand how can you make customers credit cards and information safe like Netflix with large numbers of customers with credit cards, how can they make them unreachable.
In: 3
Think of the internet like sending mails through the postal office.
We’re sending mails through the internet to Google and Facebook, but like you’ve assumed, it would be a bad thing if some busybody postman opens up our mails especially if it contains our credit card information.
So what we can do is put it in a super secure lock box (encryption), there are some really cool cybersecurity techniques that I won’t get into which ensures that only us and maybe the company we give our lock box to has the keys to open it. This key is your password, which only you know about. They have the lock box but not the key.
And by logging in, you are opening that lock box to view your secrets inside. Some hackers somewhere could probably steal the lock box, but even they won’t have the key to open it lest they trick you into divulging your passwords.
Most websites don’t store your credit card info. There are some very stringent rules about processing such information and even more stringent ones about storing them for longer than absolutely necessary.
This is why most websites with shops outsource that part to a payment processor who specializes in this exact thing. It is complicated enough to do right and comply with all the rules of the credit card companies and laws of the various countries that most smaller companies can’t afford to do it themselves and only the really large companies can do themselves without resorting to a specialist company.
If you build a webshop yourself you just tie into one of the credit card payment processors and let them do it for you and don’t have to worry about everything.
It’s all about encryption! Companies like Google and Facebook use advanced security measures to protect customer information, making it virtually impossible for hackers to access sensitive data.
This is a very loaded question with a lot to it as data can be at risk when it’s being transported or is at rest or in a cloud/on prem, but if they’re storing the info (like a saved card in the Starbucks app) it’s into an encrypted database. You’re using an interface likely two layers away. Typical system architecture for big company systems at a very high level usually go database on the bottom (single master resource) -> application layer (usually a few different ones that split the business process tasks) -> and the front end interface. Regardless of if it’s stored permanently the transaction process when you put your card into a site the payment merchant will securely transfer the transaction information with the data to their payment gateway. The payment gateway transfers the transaction information to the payment processor used by the merchant’s bank. Typical security measures (encryption, firewalls, DNS filtering, Etc) need to be applied and maintained but the process is designed to be secure and use and drop data then roll into a new transaction or process when memory is available. Bad actors grabbing credit cards from hacking a website isn’t really typically what’s going on when there are those data breaches and attacks on big companies like that, it’s usually phishing and social engineering behind it.
They can’t. Not 100% failproof anyway. That’s why there are always leaks.
But they protect credit cards the same way they protect other sensitive information like your password.
Generally speaking, the information is encrypted and stored somewhere. The key to decrypt it is stored somewhere else so that even if you get access to the system where the information is, you still need to get access to where the key is.
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.
The answer to the question you asked is with a lot of backend engineering/security work and government compliance. Making sure that data is always encrypted and the encryption keys are well controlled.
The answer you need is that if you don’t operate at a pretty large scale, it’s not worth the investment to do all the security work required to do payment processing. Instead use a 3rd party payment processor like PayPal.
Latest Answers