Account Security Tips

These days it’s more than ever very important to ensure that your data is as safe as possible. Not just by making sure your password is safe/strong enough but also by making sure that you don’t provide more information than necessary. Or at-least by only sharing information you don’t ‘care that much about’ if it somehow got leaked out. We for example decided to keep the options to enter personal information to an absolute minimum, but there are plenty of websites where you can enter your full personal details while there is absolutely no need to have all that information about you. However sometimes you do need to enter more than just your email address and a password, for example when checking out at a webshop. In this article we’ll try to give you some basic tips and information in regards to your online security. These tips are not just for use on our/my platforms but cover basically all websites, apps and services where you can or need to enter your personal information.

Especially for the TL-DR people out there
We all know you’re out there, and I have to admit that I’m sometimes also one of them. So for those ToLong;Don’tRead people, I have put a short summary here:

Only share information you need to share, or information that is ‘non-crucial’ (aka on a need-to-know basis)
- Example: Do not just share you home address with ‘any random forum’ on the internet if you don’t even know why they need it.
- Sure you can put your twitter account in your profile, but don’t just randomly enter your (mobile)phone number if you don’t know why they need it or if it’s actually kept private! (And then still (re-)consider if you think it’s ‘justified’ that they will have your (personal) phone number).
If possible use different email addresses for important, regular private and misc services/websites
Use a different password for every website, service, app etc
Use a strong password which takes the following into account:
- Use at least 12 characters
- Use at least one upper character (A-Z)
- Use at least one lower character (a-z)
- Use at least one number (0-9)
- Use at least one special character (!@#$%^& etc) [Note: Not all characters are allowed at all services/sites, keep this in mind!)
- Do not use ‘common words’ in your passwords (aka dictionary words)
  - Important tip: Even ‘obfuscated words’ like for example ‘Vacat10n‘ are considered as not safe!
- Do not use birthdays, wedding days or any other personal dates in passwords
- Do not use (family or pet etc) names in passwords
- Do not use simple ‘counting’ passwords like 12345
  - Do not use something like Abcde123456# either (is still very easy to crack!)
IF for ANY reason you need to give someone else your account details to login somewhere, then always change your password to something fairly simple (which looks NOTHING like your own!), and immediately change it back after that person is done.
- IF you really need to share (any) account details, then always re-consider if there is absolutely no other way to get the help you need without sharing your account details.
- EXTRA: Also make sure that if you had to give someone else your account details, that this person did not created an ‘backdoor’ for him/herself!
  Like for example: Is it possible that this person has created an ‘additional account’ for him/herself? Then check if he/she did this!
- Keep in mind that if you are sharing your account and/or it’s details with someone else, that you are still the one whom is held responsible if something happens. To take a simple example: If you would share your account on a platform like Xbox or Playstation with somebody to ‘help you out’, and they are caught cheating which will get you banned, then it is your problem. And it is highly unlikely that you will get your account back when saying something like ‘but it wasn’t me, I promise!‘ (It just doesn’t work like that).
- Your account(s) are your responsibility, which also means that if you ‘share account details’ that it’s your responsibility to do so.
If you have ANY reason to suspect that your password has been compromised, then make sure to change it immediately!
If you receive some ‘sketchy email’ about a company, service, website, bank etc, needing your information: DO NOT just click on any links in that email and do not start filling-in information on that link! But instead take extra time to absolutely confirm if the email is legit.
- Check the sender email address carefully and see if it matches the actually website/service you are expecting it to be.
- HOOVER on the links in the email (as in move your mouse cursor over them) and look at the status bar (often at the bottom of your screen) or pop-up-tooltip to see what the actual address is which you are going to visit when clicking on it.
- Keep in mind that decent ‘important organizations’ (like banks, insurances etc) will never ask for your personal details, account numbers, passwords etc via email! IF such organizations require action from you in regards to your account, then they will often send an email which states that you need to take action for your account and that you can find more information after logging-in. HOWEVER then still do NOT use the link in the email unless you are absolutely certain it actually came from said organisation. Instead just go to their website or app yourself directly (without using any links in the email) and check there if the email/request was indeed valid.
- Many organisations (including banks) often have an email address or website form where you can report possible fraudulent emails and such. Make use of this opportunity if they have it and report any fraudulent attempts to obtain your information in regards to their services.
- I know this will sound kinda like something that’s going to ‘Bite myself in the *ss’ but: Pay attention to grammar and spelling in such emails. I know that I myself will often ‘get caught’ on spelling and grammar errors due to my severe dyslexia (despite the fact that I do use spell-checkers, it will slip through). However official organizations like banks and such are not likely to have several (severe) grammar and spelling errors in their emails and such. Which is however often the case with these ‘scam-emails’. Do be warned though: These scam emails are getting ‘better’ (as in more realistic) each day! So be warned.
And most importantly: Use your common sense, it it sounds too good to be true, then it probably is

Well now onto the more elaborate parts of this article.

The most secure data is data which isn’t there

Do not share more than needed
Our main and most important tip (not just for our platform, but everywhere) is: Do not share more than you need and than what they (absolutely) need to know! This goes for personal details, billing addresses, email addresses etc. Websites asking for your email address the second you first visited them? NO, WHY? Just look around and then you decide if you want them to even have your email address and if it’s really necessary that yet another company starts spamming your inbox with their advertisements. Sure, if you want their news letter, just sign up no problem. But do not just enter your personal details just about anywhere.

Use different passwords everywhere
The next part (and mainly your responsibility) in keeping your data and accounts safe is to make sure that you are using secure passwords, and that you use a different password for every company, platform, service etc. And I mean literally EVERY company, platform, service etc!
Yes this might seem to be a ‘major hassle’ but it’s actually easier than you might think (we’ll discuss this a little further on after some more basic tips).

Change your password to something simple if you ever have to share it with someone
Like the title of this paragraph already suggests: If you ever (for whatever reason) have to share your account details for something with someone else, then make sure to change your password to something relatively simple (so you don’t compromise your own ‘password technique/algorithm), and immediately change it back to your own when said person is done. Do however always check if said person didn’t created a ‘backdoor’ for him/herself (if this is possible of course). And I mean ALWAYS check for something like this, even if you think you can blindly trust someone. Keep in mind here: The most terrible things can happen from the people you least expect it from!

Use different email addresses for important, ‘regular private stuff’ and ‘other random junk’.
What I intend to say with this, is that if you’re using three different email addresses for these category’s that you’re already creating another ‘safety barrier’ when one of these addresses is being leaked out through a security breach somewhere. And if this would then happen for example with your ‘important email address’, then you would also instantly know at which services you would need to change your password(s) if this happens. If you however just use one email address for everything (including your banking stuff, insurances, forum accounts, gaming platforms etc), then this is basically just ‘an disaster waiting to happen’ so to speak. Of course it’s still possible that your insurance company falls victim of a data-leak and thus also leaks out your ‘important email address’. But if you already have taken precaution in creating a unique password for every service, then this problem is already much less severe. Plus that chances are that places where you would use your ‘important email address’ are already much more secure than ‘the average gaming forum’ you would signup with (at-least let we hope they are! ;)). Three examples of email addresses you could use are:
Important/serious: JohnBiz@example.com
Everyday Mail: JohnEvd@example.com
Other/Clutter Stuff: JohnMisc@example.com

These addresses are still easy for others to recognize as yours, and due to the added ‘tag’ you instantly know which type of email it is. And if you keep these tags the same (your own ‘made up tags’ of course that is) you also quickly remember all three email addresses without the need to write them down.

– But that would mean that I now will need to login to each email address everyday to check if there is any mail I need to respond to!
No, that’s not something you have to worry about. Because with most email providers (even the free ones) you can setup ‘auto forward rules’ in the settings so that all email is automatically forwarded to one email box. This way you only have to check one email box to see if you had mail on any of the three addresses (some even allow you to create aliases).

You can also choose to use an email client (program/app) and set it up so that it receives email from all (three) of your email addresses. This way you can also send email from the desired email address directly from within one application.

Small warning though: If you decide to forward the email from your ‘misc’ and ‘everyday mail’ to your ‘Important Email Box’ and you hit reply in that email box, the receiver will then also have your ‘important email address’ due to you replying from that email address! So either make sure that you login to the correct email box to reply with, or that you’re using an email client which support multiple email addresses.

Windows 10 has the Outlook app which works great for outlook.com email addresses (but can also be used for other email providers), and if you are looking for something ‘more serious’ with more capabilities, then I would personally recommend Mozilla Thunderbird (free).

Extra tip for domain owners and mail-server owners
If you have your own domain (like a website domain) or own mail server, you can often enable an ‘catch all’ address. This address will ‘catch’ ALL (hence the name) email send to your domain. so lets for example say you made an address “CatchAll@example.com” and told the server/host that this is your ‘catch all’. Then all email which is send to your domain to a ‘non existing email address’ will be sent to this address. So if ‘john@example.com’ does exist but ‘jane@example.com’ doesn’t, but I would then send email to ‘jane@example.com’ anyway. It would then arrive at your catchall@example.com inbox.

Why is this handy? Well it’s particularly handy for website you don’t completely trust in keeping your email address private. Let’s say you want to sign up at an site you don’t trust called ‘SketchySite‘. You can then enter your email address when creating a new account there as: SketchySite@example.com and you will still receive the email through the use of your catch all email address. And IF this email address suddenly starts receiving spam, or suspicious emails, then you instantly know ‘whom to blame’! 😉

Some email/domain providers also support/allow ‘appending’ to your email address, which is a technique which I’ve been using for years actually and it has proven its use more than a dozen times already (as in website whom had ‘sold data’ ratting themselves out this way). The way it works is like this:
Let’s say your regular email address is John@example.com. But when signing up at ‘SketchySite’ you will enter your email address as ‘John+SketchySite@example.com’. With most providers whom support this, email sent to this address will still end up being sent to the mailbox of john@example.com.

If they then “sell your email address” (or leak it), you will instantly know that it was due to this website. What’s even funnier, is that some of these ’email collection bot systems’ actually DO NOT support the + in the email and due to that ‘trim off’ the part before the +. Which would then result in them sending email to sketchysite@example.com. And thus yet again you instantly knowing which site was the culprit 🙂

NOTE: Do test and experiment with this before actually ‘applying it in the wild’ to ensure that this actually works for your domain and/or server. I personally haven’t tested this with free email providers like outlook and gmail, but I would recommend just not doing this if you do not have your own email server or webdomain! Just to prevent that your (personal) email messages might end up at someone else his/her mailbox or that you accidentally ‘dump cr*p email’ at someone else their mailbox.

Creating unique strong(er) passwords
It’s not ‘that difficult’ to create unique and strong(er) passwords. You can make up your own ‘algorithm’ to create a new password for every website/service you use. There are several ways which numerous websites recommend like for example taking an sentence and then only taking the first letter of each word, adding a capital letter for each second word and adding a special sign (like #) every third word. Sounds complicated right? Well it isn’t that difficult once you’ve memorized it. Let’s look at an example of this, lets take the following example sentence and make a password of it:
‘My first house I lived in was at Home Av 233 / and the rent was $500 per month.‘

With the ‘rules’ set above that would turn out like
MFh#ILi#WaH#a233/At#Rw$500P#m.

Yes this definitely looks like hell to remember right? Well trust me: You will get the hang of a password like this quicker than you might think. You could even leave out the # and you would still have a quite ‘secure’ password (due to the fact that the $ is included here, you already have at least one ‘special character’).

BUT Would I actually recommend using a password like this? NO!

Because the problem here is that this is just one password. And when you would have to start remembering different ‘sentences’ like this for ever site and/or service you use, it does become a hell (even an impossible task to do!).

So my personal recommendation is to create your actual own “algorithm” and use ‘fixed parts’ in your password while making certain parts of it dynamic.
“Holy cr*p, that sounds even more difficult!” No it’s not, but it is A LOT safer.

I will explain a VERY simplified version of this method so it’s easier to follow and see, but if using this technique yourself, PLEASE use a longer and better ‘fixed part’ of your password!

Let’s for simplicity sake say that my fixed part will be made of the following ‘base sentence’: ‘My first dog’s name was Fido/ he lived to be 11 years old‘.
We’re NOT adding extra ‘signs’ for this example to keep it simple but will follow the ‘capitalize every second word rule’.
So when ‘converting’ our base sentence to our ‘Fixed Password Part’ this: ‘My first Dog’s name Was Fido/ he Lived to Be 11 years Old’ will result in:
MfDnWF/hLtB11yO. Already quite a useful password to use, however it’s not secure to use this same password everywhere.

So we’re going to use this base password to ‘add dynamic parts to it’. For every service/website/app you’ll use you will add dynamic parts of the name of the service/website/app to fixed locations of your base password.

– Tjees, it starts to get even more complicated doesn’t it?
No, really once you’ll understand what I mean, it’s actually quite simple to use and remember.

Lets say your going to use the first two letters of the ‘brand name’, the fourth letter and the second to last letter of the brand name.
So if you would create a new password for lets say Twitter, then you would use the following letters of Twitter
Now you could add the second to last letter (e in this instance) to the start of your own base password, then add the first two letters of this ‘dynamic’ (Tw) part after the second word of your own “base password”, and the fourth letter of the dynamic part (t) to the end of your base password.
Your base password with the dynamic parts for your Twitter login would then look like this:
Your Base Password: MfDnWF/hLtB11yO
Base Password With Twitter: eMfTwDnWF/hLtB11yOt

Yes, I know, this seems like something very difficult, but I promise you: It really isn’t. Because all you have to do is basically remember your own base password and then ‘read the screen’ for the current brand/site/app you’re using to ‘see’ the other letters you need. And when memorized, you know where to put those 🙂

Some other examples of this technique using ‘your base password’:
Facebook: oMfFaDnWF/hLtB11yOe
Instagram: aMfInDnWF/hLtB11yOt
Reddit: iMfReDnWF/hLtB11yOd
Patreon: oMfPaDnWF/hLtB11yOr

Yes, again: I understand that looks very difficult and might even look like ‘password hell‘. But this is one of the safer ways to remember unique passwords for every platform without the need to write them down (which is obviously also an security risk), and without the need to use a password manager to store all your passwords. And of course you will need to ‘design’ your own password’s ‘base’ and how you’re going to use/implement your ‘dynamic parts’ in such a way that it is easy for you to remember.

Tip: A Solution for ‘brand names’ which are shorter and would not fit your ‘technique’ which for example requires you to pick the ‘sixth letter’ from a brand name would be to ‘rollover’ to the start of the name again. So for example lets say for Twitter this would work out fine and you would get the letter e. However for a brand/service name like Xbox this would obviously not work. So here you would just rollover as this is called in ‘computer terms’. which basically means that you just resume counting from the beginning again. So then the ‘sixth letter’ in Xbox would just be b.

– Yeah, yeah, yeah. That’s all nice and well, but you just mentioned something like a password manager. Can’t I just use one of those?
Sure, you can use one of those. However personally I find that those have some cons:

All your sensitive data is in one place
If you lose access to the service/manager (either by forgetting your main password or due to the service being down for example) you don’t have access to ANY of your stored passwords.
If someone gets, guesses or ‘hacks’ your ‘main password’ (which grants access to your password manager) they instantly have access to all your passwords, but often also the usernames, urls etc which go along with that password. This is also called a ‘single point of failure‘.
You might store super random, long and safe passwords in your safe, but reality is that all your other passwords are ‘just as safe’ as your main password. Because if that password is compromised all others (no matter how difficult they are) are also exposed due to it. (Yet again this ‘single point of failure‘)
You rely on the security of the password manager, its encryption and possible bugs to keep your data safe.

Sure password manager also have their advantages, as in that you don’t need to remember each password. The good ones often have very high encryption build-in. There are offline password managers (to keep your data away from ‘internet servers and such’). But my personal opinion is that it pays off way more to make up your own complex (but simple to remember for you) ‘password system’ and to just remember that system.

This way you do NOT need to actually remember every password for every website you use, but only your ‘own password system/algorithm’.
The upside to this is that you basically always have all your passwords ‘with you where ever you go’, they are not stored anywhere else, and they do rely on some external factor (either (web)service or software program).

In the first few days (or even weeks if you’ll need that, no shame in that) you can even write down the ENTIRE sentence you’ve used to make your base password so that you have a little ‘cheat sheet’ to get used to it. Just make sure that you DO NOT write down the actual password anywhere or that you write something like “My password system” on that same note (obviously ;)).

Once you’ve memorized your system, you can dispose/destroy the note and you’re set 🙂

A data leak can happen everywhere at any time
Even if your password is strong/safe enough, the scripts on the server you are visiting are ‘secure enough’, the database and it’s passwords would be ‘safe enough’, there are always risks when storing data on internet connected machines. For instance on web-servers it could even ‘go wrong’ when the hosting provider itself has a security breach. Or when the (web)host that is being used is utilizing a ‘poorly configured shared hosting platform’, where one of the other websites hosted on the same server creates such a large security leak that access to other sites/databases is granted through their leak. It can even happen due to a bug in (security/encryption) software which is widely used and trusted! This for example happened almost 8 years ago with the Heartbleed bug. This bug was the cause of millions or data records being leaked out. So without trying to ‘freak you out too much’: there are plenty of risks which should be taken into account when posting (aka “publishing”) and storing (your) data online.

This is yet again one of the reasons to always re-consider the following: Does this website, service or app really need all the information it’s asking for? My own personal rule of thumb kinda is: If an (mostly) app asks for all kinds of permissions and personal data while it’s not clear to me why they need it, and nor do they provide any form of clarification why they need it: It’s a gonner, simple as that.

A small example of this is an flashlight app I needed to install a while ago on a phone which did not had the build-in flashlight feature in Android back then. This app on it’s first start asked permission to get access to: [The Camera], [Contacts], [The Phone Dailer], [SMS Messages] and more. Well [The Camera] I can understand, because the flashlight on many phones is actually part of the ‘camera hardware’. HOWEVER, there is absolutely no need for an flashlight app to gain access to all the other listed feature and data! Sure you could argue that it’s just ‘poorly programmed’ and that they have forgotten to turn off those requests, or that they are ‘just’ using it for ad-targeting. But either-way it does give ‘yet another app‘ access to your personal data without you being able to see what’s actually going on with it behind the scenes (in the source code). So: NO, it’s not going to happen. Just be careful with giving permission to any type of consent in regards to sharing data and/or personal information. I’m not claiming that this particular flashlight app actually had any intentions of stealing my data! But considering that it was just ‘one simple form with one tacky on/off switch‘, but did requested access to all the previously mentioned information. I actually suspect that the developer of the app didn’t even knew (yet) how to properly setup app and security rights when developing said app. And that is actually when it can become a problem: A simple app, which has all permissions set to ‘full open’ but has no internal security, encryption or whatever itself. This could potentially in worse case scenario’s lead to apps like this actually being the ‘frontdoor’ for a much more severe exploit of your data.

How (your) data is actually being stored (basic explanation)

[NOTE: This is quite an ‘extensive‘ paragraph on how storing passwords and email addresses work, you CAN skip this paragraph, but it’s recommended not to, because it does give some basic insight in how your data (passwords, email addresses etc is handled by nearly every website/service out there!]

I will provide some (basic) information on how passwords are stored these days. Most (decent!) websites, services and applications store passwords in their database with a one-way-encryption. There are various algorithms and methods possible here like for example encryption, hashing and often additional ‘security measures’ like salting are used. Without going to much into detail I will try to explain as simple as possible with an (older outdated) once very popular hashing technology called MD5 Hash (which is unfortunately still being used way to much despite it’s security flaws).

MD5 is/was an one-way-hashing method. It would take your input and turn it into a so called digest hash.
Let’s make a small example where you would have used the name of your dog ‘Fido’ as password:
Your input (password): Fido
MD5 Output/Result: 8c9d6ab4e40ea7fdd314d6f2f9f65341

Here the MD5 result would be stored in the database (and not just the so called ‘plain text’ Fido). This at first sounds ‘great’ because the website owners are not able to read/see your password at all. And because such an hash is basically one-way, it’s not possible to ‘reverse the calculation’ either.

– But how does the website then know if my password is correct when I enter Fido in the password box you might think?
Well that’s very simple, once you’ve entered the plain text Fido into the password-field the website will do the following when you press login (submit the form):
UserloginForm->PasswordField(Containing Fido)->MD5->Result(8c9d6ab4e40ea7fdd314d6f2f9f65341)
THEN it takes the result it got from the MD5 during your submit and compares that result with what’s stored in the database. So basically the website will compare your ‘just generated hash’ with the one which is already stored in the database and if those two match then it will resume logging you in, and otherwise show an error message.

– Now you might think that it’s then ‘safe enough’ to just use any password, name, pet’s name, spouse, date etc as password (since they are ‘hashed’ anyway) right?
Well no, despite the fact that these hashes are ‘non-reversible’, there are databases (tables) out there which contain millions to billions of known hashes. These databases/tables just compare the entered hash (8c9d6ab4e40ea7fdd314d6f2f9f65341 in this example) with all the values they already have, and if they find a match, they also know what the hash was supposed to be (reverse lookup is what this is called). If you would just do a quick google search on ‘reverse MD5 Hash‘ and enter the hash ‘8c9d6ab4e40ea7fdd314d6f2f9f65341‘ at one of those sites, you will instantly get Fido as result.

Another problem with this basic hashing is that if two users have a dog named Fido and both use their dog’s name as password that their password hash in the database will also look the same:
Username 1: Erik
Password: 8c9d6ab4e40ea7fdd314d6f2f9f65341 (Fido)
Username 1: Bert
Password: 8c9d6ab4e40ea7fdd314d6f2f9f65341 (Fido)

It would already yield a different result if Bert had used only lowercase letters (fido): 5e144c3fc80e2fe1c8abc5925ab914a8
For us as humans this looks like a completely different password when we look at the hash, however when computers are put to work with an dictionary attack for example, Fido would have been found just as fast as fido. Both because it’s a very short password, and the fact that it’s probably a password which has already been used millions of times around the world and thus is also present in many (if not all) reverse hash tables/lists.

So to overcome this problem some websites apply ‘salting’ (as mentioned earlier) to their hashes. This means that they add a bit of extra data to the ‘plain text’ before it’s being hashed. However it’s very important that this ‘salt‘ is unique per user, otherwise it would still result in the same hash if two users had the same password. So lets give two quick examples here (both users using the password Fido again), for user one we’ll add ‘Salt1234‘ as salt, and for the other user ‘SaLt5678‘ as salt (all this happens behind the scenes when you press submit/login/send etc).

So for user 1 Fido would (behind the scenes) become: FidoSalt1234 (Resulting in: a0277242e4a824708c5df15776f05349)
And for user 2 Fido would (behind the scenes) become: FidoSaLt5678 (Resulting in: 76a08cd64b3ddf306b37de7ff46657a0)

As you can see, both users (even despite the fact that they are using exactly the same password on entering it, their hash in the database looks completely different due to the ‘added salt’. This makes it for admins impossible to see at first glance that the passwords for these users are exactly the same when looking in the database itself. However for an attacker it’s just a small setback, meaning they would need just a bit of extra time to discover that the passwords are the same. Most attackers who really need the information they are after are using very powerful machines (or even entire server parks) which are put to work to decode password lists. Just adding one so called ‘salt‘ to the passwords would just slow them down a bit at it’s best.

Which is why lots of services also use additional encryption or hashing techniques like multiple passes of hashing (often combined with unique ‘salts’). However all these measures in the end merely slow down attackers if they really want or need the data. Depending on how the data is stored (encrypted/hashed etc) it’s more of a question how long it would it take an attacker to ‘decode’ it. And combining that with the possible “value” they will get out of the compromised data(base) determines if its worth enough for the attacker to spend time and/or resources on.

If an attacker already knows (or suspects) that the only data he/she will gain from decoding a certain database entry would be your email address (which would for example already be available openly on your own website), then the attacker has no use in wasting his or her time in decoding such entry’s.
If however said database also contains lots of personal information like your (home) address, full name, banking details and such, then it’s suddenly A LOT more interesting for an attacker to actually decode the ‘encrypted or hashed parts’ of the database. Because these extra bits or data (which are currently encrypted) could ‘just be the key’ to a “full-blown identity-theft situation”. And if you then also happened to have used a simple (to decode/reverse lookup) password AND are also using that same password everywhere else…. Well then you’re a long way from home in regards of recovering from such a data theft!

The other problem of using simple passwords, is still a lot less technical and more human than you might think: They are way to easy to guess during a ‘trail-and-error’ attempt of someone (thus someone just manually trying to guess your password).

– And what about information like our email address?
While most websites and services store passwords in some sort of hashed or encrypted way these days, there are still plenty (if not the majority) of websites which don’t use any form of encryption for data like email addresses, usernames, (billing) addresses etc. You might think “wait what??, they are storing my information without encryption on their servers??”. Well the short and plain answer to this is: Yes, they are.

But the reason(s) why they do this aren’t that simple to explain. Yet again I will try to keep this as simple as possible though.
As explained before, hashing is only a ‘one-way-street’. So if your email would be john@example.com and it would be hashed (with the earlier mentioned outdated MD5) it would turn out like this: d4c74594d841139328695756648b6bd6

This would become problematic if said site would for example be a web-store which needs to send you emails with product updates, invoices etc. Simply because there would be noway to ‘reverse d4c74594d841139328695756648b6bd6 back to john@example.com‘, and I assume we all understand that just sending an email to d4c74594d841139328695756648b6bd6 would not work ;).

Therefor we would need a different solution to safely store email addresses by encrypting them on saving, and decrypting them when needing them to-do something with it. The ‘use-chain’ (to call it that for now) would then be something like this (NOTE: This is just an FAKED example):
john@example.com[input from user]->Encrypt(john@example.com, SecurityKey)->F4ffo4$ddo4dk5vkfor$4f944s(Result)->SaveInDatabase
So this would then after you’ve entered the email address result in F4ffo4$ddo4dk5vkfor$4f944s being stored in the database.

However if we now would need to use the email address for anything (from showing it on your user profile to actually sending an email), we would then first need to decrypt it using our so called ‘use-chain’:
F4ffo4$ddo4dk5vkfor$4f944s(EmailInDatabase)->Decrypt(F4ffo4$ddo4dk5vkfor$4f944s, SecurityKey)->john@example.com(Result)

This all seems perfectly fine and secure right?
Well no, there is actually one major problem with data in the database that can or needs to be decrypted: the SecurityKey.
The SecurityKey if a unique piece of text, string, password (or whatever the person who wrote the code decided to use) which is needed to actually encrypt and decrypt the entered data. And because the website/application/server etc needs to know this SecurityKey, it has to be stored somewhere on the server (either in a file or in the database) so that the server has access to this SecurityKey when it needs to Encrypt or Decrypt something.

And that is exactly where the problem arises: If this key is stored somewhere on the server, then an attacker also has access to this SecurityKey (or keys if using multiple keys) when there is a data-breach. In the ‘best case scenario’ (as far as possible with a data-breach though) the attacker only gets access to the database which contains the encrypted keys and not to the keys which are in this example stored in an external file. But this scenario is not quite likely, often if an attacker gains access to the system he or she will have access to the majority of the system.

– But wouldn’t it be possible to create some special script which encrypts with a different SecurityKey for each user/entry?
Yes, it would be possible and is actually not uncommon to-do in various situations. However! When doing something like this on a web-server, the scripts to do this (and thus their algorithm to generate these SecurityKeys) are also stored/”installed” on the same server.

Which in it’s turn yet again means that if an attacker gains access to the server (and thus these scripts), he/she yet again knows how to decrypt the data from the database. These complications plus the extra overhead (in computing power required to Encrypt/Decrypt all the data on the server constantly) often result in such data which need to be usable in two directions (like email addresses) being stored unencrypted.

All these things mentioned above might sound quite scary for someone just reading it for the first time, but that’s exactly why I’ve written this ‘security tips’ page and how you can do your best effort on keeping your data as safe as possible. And why it is so important to memorize the earlier points when it comes to your data, security and the internet:

Disclaimer for the more tech-savvy among us:
I’m aware that the information isn’t 100% accurate, that it describes several outdated methods (like MD5 for example), that it ‘lacks to mention’ things like openssl_encrypt, the deprecated mcrypt_encrypt, that it’s lacking many other practices like SQL Injections (which obviously do ‘only’ give access to the database), that it used ‘extreme examples’, or on some parts could have been more elaborate. But that all isn’t the point here, my main intention was/is to inform people/users a bit more on internet security and how their data is being uses in a ‘global sense’. And even if this article has made one person more aware about his/her online security and how to actively contribute to it, then I’ve reached my goal 🙂

Global Disclaimer
This article does not tell you ‘the best way’ to protect your self, neither does it give you any guarantee that your data will never be stolen, leaked or abused anywhere (that’s just impossible to guarantee at all). And neither do we/I accept any responsibility if you use this methods and still do fall victim due to a data-leak. These methods aren’t fail-proof (no method ever can and will be!), and as explained several times: The safety of the data being stored depends on many factors of which mostly are not in your or our control (like for example security library’s with bugs and such).

Last updated: 18-02-2022

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
cookielawinfo-checkbox-videocontent	11 months	This cookie is set by GDPR Cookie Consent system. This cookie is used to store the user's consent for cookies in the category "Embedded Video Content" and allows (or disallows) showing embedded video content on our platform.
CookieLawInfoConsent	11 months	The cookie is set by GDPR cookie consent system and it Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
store_notice[notice id]	session	Allows users to dismiss the store notices which might be shown at the top of the page during special announcements, events or during maintenance for example. It does not store any personal data.
viewed_cookie_policy	11 months	This cookie is set by the GDPR Cookie Consent system and is used to store whether or not the user has consented to the use of cookies. It does not store any personal data.
woocommerce_cart_hash	session	This cookie helps our project and product 'store' determine when cart contents/data changes. It does not store any personal data.
woocommerce_items_in_cart	session	This cookie helps our projects and products 'store' determine when cart contents/data changes.
wordpress_logged_in_[hash]	session	The cookie is used to remember that you are logged in, and who you are. Without this cookie the website would not be able to recognize you as being logged-in. The [hash] part represents the value which is generated by applying a specific mathematical formula to the username and password. This is to ensure that the input values are safe and no one can access this data using the cookies.
wordpress_test_cookie	session	This cookie is set by the website to test if it can actually set (any) cookies, this is necessary to ensure all other functionality like logging-in, storing whether you allow certain cookies or not etc. This cookie does not store any personal information.
wp_lang	session	This cookie is set by the website's framework by default so that it knows which language it should use. This cookie does not store any personal information
wp_woocommerce_session_	2 days	This cookie contains a unique code for each user so that it knows where to find the cart data in the database for each user.

Cookie	Duration	Description
_twitter_sess	session	This cookie allows the use of Twitter features without having to log in, and contains some tracking information that Twitter uses to improve their services. (However IF Twitter indeed does what it says, the tracking part should be disabled due to the DNT (do not track) setting).
# IMPORTANT PLEASE READ!	various	This is additional information, not a cookie! The cookies listed here are just a few of the cookies which will be set by the Twitter Timeline, there are (quite a lot of) other cookies which are also set by the Embedded Twitter Timeline when it's enabled. We do have enabled the enhanced privacy options ("do not track") features of Twitter for this Timeline, we however (of course) do not have control over possible cookies set and/or created by externally embedded content. This is also the reason why we disable the content altogether when you don't allow their cookies. You can view which cookies exactly are being placed by websites using the developer console of your browser, where and how to find this depends on your browser, but for most browsers this can be opened using F12 on your keyboard. Please make sure that you understand that externally embedded content (like the Twitter Timeline) does place additional cookies which we are not able to all list here!
ct0	11 months	This cookie is set due to Twitter integration and sharing capabilities for the social media.
dnt	12 Months	This seem to be the Do-Not-Track / Do-Not-Taylor cookie, telling the widget not to track/taylor your content depending on our website/widget. Considering this cookie only appeared when we enabled the Privacy feature of the Twitter Widget.
guest_id	11 months	Unspecified
personalization_id	13 months	This cookie is set due to Twitter integration and sharing capabilities for the social media.

Cookie	Duration	Description
_gads	13 months	This cookie is associated with the DoubleClick for Publishers service from Google. Its purpose is to do with the showing of adverts on the site, for which the owner may earn some revenue.
# IMPORTANT PLEASE READ!	various	This is additional information, not a cookie! The cookies listed here are just a few of the cookies which will be set by our advertisement provider, there are (quite a lot of) other cookies which are also set by the advertisement provider (Google/AdSense/Doubleclick) when it's enabled. We do have enabled the enhanced privacy options ("do not track") features for these advertisements, meaning they should only show completely unrelated and non personalized advertisements. We however (of course) do not have control over possible cookies set and/or created by externally embedded content. This is also the reason why we disable the content altogether when you don't allow their cookies. You can view which cookies exactly are being placed by websites using the developer console of your browser, where and how to find this depends on your browser, but for most browsers this can be opened using F12 on your keyboard. Please make sure that you understand that externally embedded content (like the advertisements) does place additional cookies which we are not able to all list here!

Cookie	Duration	Description
# IMPORTANT PLEASE READ!	various	This is additional information, not a cookie! The cookie listed here are just a few of the cookies which can be set by the embedded video player(s), During multiple tests did not encounter any other cookies being placed by the embedded player accept about 4 ("randomly named") cookies once or twice during some extensive testing while using Chrome (other browsers did not seemed to do this). We however (of course) do not have control over possible cookies set and/or created by externally embedded content. This is also the reason why we disable the content altogether when you don't allow their cookies. You can view which cookies exactly are being placed by websites using the developer console of your browser, where and how to find this depends on your browser, but for most browsers this can be opened using F12 on your keyboard. Please make sure that you understand that externally embedded content (like the Embedded Video Content) can or does place additional cookies which we are not able to all list here!
CONSENT	11 months	This cookie is placed by the youtube-nocookie.com domain, we suspect that it is used to tell the player that 'consent for cookies or user-tracking' is pending (and thus should not happen) because the data within this cookie says: "PENDING+162". However we unfortunately can't confirm this because there is almost no other website or information available about this cookie. And despite the fact that almost ANY website with "GDPR Compliance Tips" tells you to "just use the YouTube-nocookie feature" to be GDRP Compliant without having to ask user consent, we do not agree! Due to the simple fact that it does still place this cookie. And due to the fact that when enabling the "YouTube Privacy Enhanced feature" it gives a popup saying: "When you turn on privacy-enhanced mode, YouTube won't store information about visitors unless they play the video.", we just don't like this kind of 'sketchy behavior' and thus require you to allow such cookies and content before we will actually display it.