Plans with Fakewords

Document Introduction

This Series & Dataroom - Anti-Hack Jobs

This document belongs to the dataroom of, Anti-Hack Jobs, of which in turn, belongs to Australian based KangaBytes as the owner and author of all content within this document.

The Anti-Hack Jobs advisory, is to advise in respect to, how best to protect the data of your customers, from hacking events.

The use of these tips, requires a license. Please visit the online dataroom at www.kangabytes.tips/pass.html for this information.

This Document - Plans with Fakewords

This document focuses on, strategies around Fakewords. These are settings that are associated with the password field, when a fakeword is entered as a password, the person gaining access at that time, will be subject to a trap being sprung, such as, being presented with fake account information.

A fakeword can work in either of these ways,
• Set a flag or other trigger, of which can close all access to that account for a period of time.
• Blackban the IP address.
• Divert the access seeker to, fake account information.

When you have respective account holders to set their own fakewords, that sets up a somewhat dynmanic system, of which can not be predicted by any hacker.

Passwords &/vs Fakewords

How they are same/similar

Each of these two types are.....
• ....entered in, by the access seeker, via the same input tag.
• ....operated through the same authentication script.

How they are greatly different

Passwords vs Fakewords have these distinctions;
• the True-Holder never needs to remember what their fakewords are each time they log in, they just need to remember what their passwords are.
• Passwords are true authentication. Fakewords are in fact meant to be a trap for hackers, and many times more of these than how many passwords there are.

BLOCKPASSES - How it Works

Opening summary

A BlockPass is a trap, meant to catch a hacker, and, to instantly put on a block on their IP Address, to prevent that hacker from doing any further hacking of that account and/or server.

By having the True-Holder set up their own small list of BlockPasses, sets up a dynamic system, of where, any word, can in fact be a BlockPass.

Why is BlockPassse better than three strikes and your out ;
• Only blocks the hacker, and not, block the account to all, including block the True Holder.
• Happens on the first use of the BlockPass, and not after three strikes of getting the wrong password. This results in a much quicker reaction to a hacking attempt.

BlockPasses - The Customer/User

NOTE: This MUST not be a doable function, during the application stage of any new customer/member.

The True-Holder

Within their account area,
• Sets a series of these BlockPasses, in respective input fields.
• The page of which is where you set your BlockPasses, MUST be a totally different page, to that of, the passwords. This is to help avoid confusion held by the True Holder.

During Log in
• Simply remembers NOT to use any of these BlockPass words during their own log in.

BlockPasses - Wordings and Meanings

Meaning of BlockedList

Means, the list of IP addresses, of which are subject to a block.

Any of the IP addresses of which are in a BlockedList should have their access blocked.

BlockPasses - Alturnate Options & Ways

You can choose, as to the maximum quantity of BlockPasses, of which your customer may use. Remember, the more BlockPass words there are, means the strike rate is that much more than, the chances of guessing the correct password.

BlockPasses - What you need

The Log-in page
• No Change whatsoever to this page.
• You only need one single {input type=password} tag, just like you do today with any existing Mono Password system of which we currently use.

Within the account area
• One page in the account area, in which the customer can set their BlockPass word(s).
• MUST NOT be on the same page as, where the authentic password(s) are to be set on. This is to help avoid confusion.

The Authenticator Script - Towards the start
• Needs to check the list of blocked IP addresses, and if the IP address of the one seeking authentication matches any of the IP addresses in the Blocked list, then, authentication is stopped, and access is blocked.
• This portion of script, must be located towards the start of the Authenticator script, to ensure that, any blocked IP address gets blocked before anything else happens.

The Authenticator Script - Towards the end
• The Authenticator needs to check the entered password against each of the BlockPasses, to find out, if any one of them, is in fact a BlockPass as set by this True Holder.
• If the previous point/test is positive, then, this IP address, now seeking authentication, MUST be added to the BlockedList.
• This IP address register, needs to be a common register, and one of which should block all access from that IP address, no matter what account they are trying to access, at that time.
• As the BlockPass system, is part of the Fakeword group, this BlockPass search and test, needs to be, towards the end of the Authenticator script, and past where all of the Password type systems are located.

Database table #1 - Your BlockPass settings
• For each BlockPass, of which you permit your customer to have, add one column like a {TINYTEXT} to hold the respective BlockPasses for that customer.

Database table #2 - Register blocked IP addresses
• You need one, {CHAR(45) INDEX} to hold that respective IP Address.
• Furthermore, you need one {TIMESTAMP} column, to register when that IP address was first directed
• And lastly, one {DATETIME} column too, to record the most recent detection of that IP address.

BlockPasses - Handy Tips

Try and ensure you have a quantity of BlockPasses, to match the quantiy of, one of your password systems. Such as, five BlockPasses, to match the quantity of five, for your QuinCycle system. To mitigate database leaks.

How to have the database tables
• A series of distinct tables, with the only difference being, the table name, and the fact they are different tables.
• Each table, holds a respective password or fakeword tip. Namely, one holds the QuinCycle system, another table holds your BlockPass fakewords, and a third table, is a trip table, also containing BlockPass fakewords.
• In the event of a database hack, the hacker does not know, as to which table contains which system of passwords/fakewords.
• Having that extra BlockPass fakewords table, the hacker is twice as likely to get fakewords.
• Furthermore, you may have, half of each password in table #1, another half in table #2.

BlockPasses - The Hacker

The Hacker

How this feature functions with the Hacker,
1. The hacker types in the guessed password into the password field at the log in page, as they do as part of any hacking event.
2. The hacker then activates send/login.
3. The server then checks the entered password, against the list of BlockPasses for that user.
4. Should the server find that entered password is in fact a BlockPass for that user, then, the server puts a block on that IP address, however, the account is NOT subject to a block.

The type of hacker that gets blocked here is, the type of whom just randomly selects a combination of characters, or, randomly selects words, starting off with dumb passwords like Pass, GetMeIn and so on.

BlockPasses - Some Risks of Note

Please Note: This list of risks may NOT be complete. You are advised by us, to seek your own, independent advice in respect to this.

Use another IP address

Many hackers will have access to a list of IP addresses. They will hit your website, that many times, until they run out of available IP addresses.

Dynamic IP addresses

One of the cheap and nastys of the internet is, how dynamic that, IP addresses are. The majority of IP addresses will change each week or so.

There is a very real chance that, a blocked IP address will change to a connection of a True-Holder, and as a result, will block a True-Holder from your system.

You must set a time limit, for how long each IP address is blocked for, and reset/clear the block on each respective IP address, once every so often. We can not specify an ideal time limit for you to have.

Demand will be high

This system may slow down the authentication process, as, the authenticator will need to search through a rather long list of IP addresses.

Furthermore; the demand on server memory will be large, especially where your website gets quite a lot of BlockPass hits.

FAKESIDE - How it Works

The aim is, for the True Holder of an account, to set a list of their own FakeSide Fakewords, with the aim of, should any hacker try and attempt access with any of those Fakesides, that hacker will then be sent fake data. The Hacker thinks, they have a success, only to waste their time with what is, pointless data.

FakeSide - Marketing & Pitching

Destroys their business model

Out of all of my tips, this must be the best one of all. With the objective of, to remove every bit of value from, the stolen data, as taken in, any hacking event.

With all that financial worth now being gone, will thereafter, remove all reason for why, much of the hacking events happen in the first place.

Short term, minor pain. Long term, major gain.

• Nobody in the hacker world, will know, as to which are real, and which are fake.
• Can you imagine what it would be like, to buy a bunch of account access information, and, only then to find out that, none of them work?

FakeSide - Wordings and Meanings

Meaning of FakeSide Data & Fake Account Information.

This is, the data and information of which is sent out, when an account gets accessed with a FakeSide password.

This is, fake data, of which is meant to look like real information, and is aimed at tricking the viewer in thinking that, this data is in fact, true data.

FakeSide Data can be, any type of information, of which is about, of, or in association to/with, a real person.

Meaning of True Data

Means the authentic data or information that is, about the true account holder.

FakeSide - The Customer/User

How they set this up

Area #1 - Entry of FakeSide passwords
• Goes into a page within their account area.
• Enters a list of FakeSide passwords

Area #2 - Set fake data
• Goes into a page within their account area.
• Enters their fake information, such as email addresses and so on.

When they log in

The True-Holder simply, avoids the use of, any of these FakeSide words during a log in event.

FakeSide - Accessibility

New customer note

Your customer should not ever, be required to set any of these FakeSide passwords, during their application stage.

Rather, your new customer should be encouraged to go into the FakeSide area of their account later on.

FakeSide - Alturnate Options & Ways

Your common or default;
• You the webmaster may, choose a set of fake data, to be colleced on the hack of all accounts in your system.
• You may also, choose, if, your customer has the right to edit this information.

NOTE:I do strongly suggest that, you have a default set of fake data, for new accounts, and, to then let your customers the right to edit that information to whatever they wish.

Optional extras
• The customer may get the option to, provide different fake information for each of the FakeSide words they have.

FakeSide - What you need

The website

Account area
• A fieldset of input tags, each one will be for a respective FakeSide in each.
• A fieldset for, fake address and/or other contact information too.
• MUST be located within a separate page to, where the true account information and password fields are located. This is to ensure that your customer does not get confused as to which is what.

Log-in form
• No changes to the form, form fields, form input tags and so on.
• You only need one single {input type=password} tag, just like you do today with any existing Mono Password system of which we currently use.

Authentication Checker
• Needs to check the entered password, against the list of passwords, across each password system before the script starts looking at the list of fakewords.
• must check the entered password, against the list of FakeSides for that account.
• Should a FakeSide be detected, then, the Authenticator will direct the access-seeker into a fake account.

Database table #1 - The FakeSides
• You need one a {TINYTEXT} or {CHAR(??)} type of column, for each FakeSide you permit your customers to have.

Database table #2 - The fake account information
• You need whatever columns, as what you currently use, to hold authentication information, like user name, email address, and so on. DO NOT include their password within this one.
• Whatever other information of which your account works with.

FakeSide - The Hacker

The Hacker

How this feature functions with the Hacker,
• The hacker trys to log in, with what they think, is a valid password.
• During the Authentication process, the authenticator, will detect that, the word used, is in fact a FakeSide Fakeword.
• The server then presents whatever fake data they like to the hacker.
• The hacker thinks that, they now have the real data of that account holder, and trys to make use of that.
• Only after all of this time, when the hacker trys this data, they MAY? then, realise that, the data is all fake.

How this hampers the hacker
• Will never be able to determine if, the data is real or not.
• Can presume the data is real, then try and make use of it, then, be blocked in the process.

FakeSide - Some Risks of Note

Please Note: This list of risks may NOT be complete. You are advised by us, to seek your own, independent advice in respect to this.

Phishing Checks

One sure way for a hacker to check if the information is real or not, is, to conduct a type of phishing event, of which can include cold calling people.

People need to be alerted to this risk, and, to be prepared for it. DO NOT TRUST anybody they do not know, on the telephone.

Avoid showing both datas

Never, show both true data, and fake data, at the same time in any account. This includes, where the two types, are across separate pages of the same account.